C H A P T E R 5 - Hotdesking (Mobile Sessions)

C H A P T E R 5

Hotdesking (Mobile Sessions)

The Sun Ray system is designed to enable session mobility, or hotdesking, with Smart Cards. Every Sun Ray DTU is equipped with a Smart Card reader.

This chapter describes how to enable users to access their Sun Ray sessions not only within a failover group (see Failover Groups) but across multiple failover groups. This feature is called regional hotdesking.

The welcome screen has an empty text field in which to enter a user name. Press Return to get the equivalent of the OK button.This figure shows a user name entered in the text field.This screen welcomes the user and prompts for a password.As in most cases, it is preferable to use the utadmin command instead of the Admin GUI screens for all administration issues, such as changing the access levels of card users and other users.This screen confirms that a change has been made to a policy.

Regional Hotdesking

Regional hotdesking can be enabled by means of multiple failover groups. Multiple failover groups are useful for various reasons, such as:

Availability

It is sometimes advantageous to have multiple, geographically-separate locations, each with a failover group, so that if an outage occurs at one location, another location can continue to function.

Organizational Policies

Some sites have different administrative policies at different locations. It can be advantageous to keep separate failover groups at these locations.

Regional hotdesking, sometimes referred to as Automatic Multi-Group Hotdesking (AMGH), is useful when an enterprise has multiple failover groups and users who move from one location to another who wish to gain access to their existing session wherever they roam. The following sections describe regional hotdesking. For further technical detail, please refer to the utamghadm(8), ut_amgh_get_server_list(3), and ut_amgh_script_interface(3) man pages.

Note - Regional hotdesking is not enabled for multihead groups.

Functional Overview

Once regional hotdesking is configured, user login information and sessions are handled as follows:

1. When a smartcard is inserted or removed from the system or a user logs in via the greeter GUI, parameters such as the username (if known at the time), smartcard token, and terminal identifier are passed to a piece of site-integration logic.

2. The site-integration software uses these parameters to determine to which Sun Ray servers it should direct the Sun Ray DTU.

3. If the smart card token is associated with a local session, then that session gets preference, and regional hotdesking is not invoked.

4. Otherwise, the regional hotdesking software redirects the Sun Ray DTU to connect to the appropriate Sun Ray server.

Thus, if the user has an existing session, the DTU connects to that session; if not, the regional hotdesking software creates a new session for that user.

Site Requirements

To utilize regional hotdesking, a site must provide some site integration logic that can utilize enterprise data to determine which users or Sun Ray DTUs should connect to which failover groups. This is ordinarily provided through the use of a dynamic C library or a shell script that implements a particular interface used by regional hotdesking software. SRSS provides some reference code that a site administrator can use as an example or adapt as required. An administrator must configure the regional hotdesking software to utilize a specified library or shell script, then implement the PAM stack of the login applications, as described below.

Note - To ensure continuous operation, the be sure to include enough servers in the target group to provide availability for session location and placement in the event that a particular server becomes unavailable. Two servers should be minimally sufficient for most sites; three servers provide a conservative margin of error.

Providing Site Integration Logic

To determine where given Sun Ray DTUs or users should be connected when creating or accessing sessions, the administrator must utilize enterprise data. Sun Ray Server Software 3.1.1 includes for this purpose:

man pages, such as ut_amgh_get_server_list(3),which describe the appropriate C API for a shared library implementation

A shell-script API, ut_amgh_script_interface(3), which can be used as an alternative.

Reference C code and script code, located at /opt/SUNWutref/amgh. This code can serve as example or be directly adapted for use.

A functional Makefile.

To Configure a Site-specific Mapping Library

The administrator for each site must determine what mapping library to use. It may be a site-specific implementation, as described above, or one of the sample implementations provided with the SRSS software.

Use the /opt/SUNWut/sbin/utamghadm command to configure the regional hotdesking software to use this library.

1. To configure the token-based mapping implementation provided as a sample, execute the following:

# /opt/SUNWut/sbin/utamghadm -l  /opt/SUNWutref/amgh/libutamghref_token.so

2. To configure the username-based mapping implementation provided as a sample, execute the following:

# /opt/SUNWut/sbin/utamghadm -l  /opt/SUNWutref/amgh/libutamghref_username.so

3. To configure a script-based back-end mapping (for example, the token-and-username-combination-based mapping sample), use the -s option to this command:

# /opt/SUNWut/sbin/utamghadm -s  /opt/SUNWutref/amgh/utamghref_script

4. Do a cold restart of the SRSS services using either the utrestart CLI or the Admin GUI.

Token Readers

To utilize token readers along with regional hotdesking based on Sun Ray pseudo tokens, use the Site-specific Mapping Library to produce the desired behavior for them.

Configured token readers should have the following value formats:

*Key	*Value
insert_token	pseudo.<MAC_address>
token	TerminalId.<MAC_address>

Note - If a registered policy is in place, use the insert_token key instead of the token key, which is not globally unique.

To Configure the Sample Data Store

Each site must configure a data store to contain site-specific mapping information for regional hotdesking. This data store is used by the site mapping library to determine whether regional hotdesking should be initiated for the parameters presented. The data store can be a simple flat file. The sample implementations included with the SRSS require a simple flat file configuration.

Create the back-end database file under /opt/SUNWutref/amgh/back_end_db on the Sun Ray server:

a. For a token-based mapping, use entries of the form:

token=XXXXXXX [username=XXXXX] host=XXXXX

Comments (lines beginning with #) are ignored.

Username is optional. If the same token is associated with more than one non-null username, an error is returned.

b. For a username-based mapping, use entries of the form:

username=XXXXX host=XXXXX

Comments (lines beginning with #) are ignored,

Key/value pairs other than those mentioned above are ignored.

The order of key/value pairs is not significant.

c. For a combined mapping, use entries of the form:

 Any combination of TOKEN BASED and USERNAME BASED lines.

Comments (lines beginning with #) are ignored,

A TOKEN match is attempted first.

If none is made (or if no username is included in the matches) the user is prompted for a username.

A lookup is made for this username. If there is no match, a local session is created; otherwise, the Sun Ray DTU is forwarded to the first host reported as available.

A sample line for this file would look like the following:

 token=MicroPayflex.5001436700130100 username=user1 host=ray-207

To Disable Regional Hotdesking

1. To disable AMGH configuration for a group, run the following command:

% /opt/SUNWut/sbin/utamghadm -d

2. Do a cold restart of the SRSS services using either the utrestart CLI or the Admin GUI.