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. Sun Ray Server Software 3.1 also includes the industry standard PC/SC-lite API for developers who wish to encode custom applications or other information in their users' Smart Cards. Custom applications are frequently used to provide strong smart card-based authenticated logins and PKCS#11, S/MIME digital signature message signing and encryption, among other capabilities. This enhancement requires no additional administration.
Configuring Sun Ray Server Software with non-smart card mobile (NSCM) sessions provides the benefits of hotdesking without the use of smart cards. This chapter explains NSCM sessions and how to configure them.
This chapter contains the following sections:
If a user does not want to use the NSCM session, inserting a smart card causes the session to be disconnected and replaced by a smart card session.
When Sun Ray Server Software is configured for NSCM sessions, the Sun Ray Mobile Session Login dialog box is displayed on the Sun Ray DTU.
A right click on the Options button opens a panel where the user can select:
When a site policy disallows NSCM sessions, DTUs configured as token readers display the token reader icon instead of the Login Dialog box.
|
1. Type a user name and then a password into the user entry field.
If an NSCM session for this user does not exist, the Authentication Manager creates an NSCM session token for the user. The token has the format: mobile.username, where username is the user's identification.
If the Sun Ray server is part of a failover group, the load-balancing algorithm may redirect the user to another Sun Ray server, where the user types a username and password again before an NSCM session is created. The Sun Ray administer can control whether the user has to re-enter a username and password pair.
If an NSCM session exists on a different Sun Ray server in a failover group, the user is redirected to the server where the most current NSCM session is located.
The Sun Ray Mobile Session Login dialog box is redisplayed with the host name of the new Sun Ray server, and the user must retype the user name and password.
If an NSCM session exists on the current Sun Ray server, the session is displayed to the user. If a user wants to move to another location, there are two methods of disconnecting an NSCM session:
To disconnect a NSCM session, the user presses the key combination Shift-Pause.
1. Type the utdetach command in a shell window:
2. Press the Shift and Pause keys simultaneously.
The Sun Ray Mobile Session Login dialog box is redisplayed, and the user moves to another Sun Ray DTU.
3. Login at the second Sun Ray DTU.
The user can terminate the session by clicking the Exit button in the CDE panel or by pressing the key combination Ctrl+Alt+Bksp twice.
Click the Exit button on the CDE panel.
Press the Ctrl+Alt+Bksp key combination twice.
You can change the disconnect key combination (hot key) in the /etc/opt/SUNWut/utslaunch_defaults.properties file, where the site-wide default configuration of the hotkey key combination is specified. Individual users can override the default key combination by configuring the ~/.utslaunch.properties file located in their home directory.
Edit the respective file and find the line with the utdetach.hotkey property.
Change the string after the equals sign to the keystrokes desired. For example, to configure the key combination of Alt + Esc, type:
|
You can disconnect the current session using the key combination (hot key) in the utslaunch.properties files.
1. To reconfigure the hot key combination, edit the file and find the line with the utdetach.hotkey property.
2. Change the string after the equals sign to the keystrokes desired.
configures the key combination of Alt+Esc.
The user login experience for NSCM sessions may be different than expected when systems are configured as part of a failover group.
The following situations may produce unfamiliar behavior:
If server A is heavily loaded when a user logs into it with the NSCM GUI, it redirects the user to server B, which may require another login with the NSCM GUI. If server B is running an earlier Solaris version than Server A, the user may have to log in a third time.
A user with a session on server A who wants to switch to a session on server B invokes the utselect GUI to access the other session. In doing so, the user is required to log in with the NSCM GUI. Users familiar with the ease of the utselect GUI might be discouraged that another log in is necessary.
The user bypasses the NSCM GUI by clicking the Exit button and logs into server A using dtlogin. The user now has a standard escape token session and invokes the utselect GUI to switch to server B and, in doing so, is presented with the NSCM GUI. The user must click Exit again to get to the escape token session on server B.
Users accustomed to a quick switch might be annoyed that they must interact with the NSCM GUI a second time.
The Sun Ray administrator can enable the NSCM session features with:
|
1. Before changing the Authentication Manager policy, inform your users that all active and detached sessions will be lost.
You can use the utwall command to send the notice of policy change. For example:
# /opt/SUNWut/sbin/utwall -d -t 'System policy will change in 10 minutes.\nAll active and detached sessions will be lost.\nPlease save all data and terminate your session now.' ALL |
The following message is seen by all users in a pop-up window:
System policy will change in 10 minutes. All active and detached sessions will be lost. Please save all data and terminate your session now. |
2. Log in to the Administration Tool.
3. From the task list, select Admin and click the Policy link.
The Change Policy window is displayed.
4. In the Non-Card Users column, check the Enable Mobile Sessions box.
When the policy change is complete, you are shown a confirmation window.
6. From the task list, select Admin and click the Reset Services link.
The Sun Ray Services panel is displayed.
7. Select Group if this is a failover group or Local if there is a single Sun Ray server.
8. Click Restart to restart Sun Ray services and terminate all users' sessions.
The NSCM sessions are enabled in a moment.
|
The Sun Ray administrator can toggle the NSCM session capability by including or excluding the -M argument in the utpolicy command. For more information, see the utpolicy man page.
1. Before changing the Authentication Manager policy, inform your users that all active and detached sessions will be lost.
You can use the utwall command to provide them the notice of policy change. For example:
# /opt/SUNWut/sbin/utwall -d -t 'System policy will change in 10 minutes.\nAll active and detached sessions will be lost.\nPlease save all data and terminate your session now.' ALL |
The following message is seen by all users in a pop-up window:
System policy will change in 10 minutes. All active and detached sessions will be lost. Please save all data and terminate your session now. |
2. As superuser, type the utpolicy command for your authentication policy with the addition of the -M argument. For example:
This example configures the Authentication Manager to allow self-registration of users both with or without smart cards, and NSCM sessions are enabled.
3. Initialize Sun Ray services.
a. Type this command to restart the Authentication Manager.
This command clears all active and detached sessions
b. Repeat Step a on each secondary Sun Ray server if in a failover group.
Regional hotdesking can be enabled by means of multiple failover groups. Multiple failover groups are useful for various reasons, such as:
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.
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(1M),ut_amgh_get_server_list(3), and ut_amgh_script_interface(3) man pages.
Note - Regional hotdesking is not enabled for multihead groups. |
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.
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.
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 includes for this purpose:
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:
2. To configure the username-based mapping implementation provided as a sample, execute the following:
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:
4. Do a cold restart of the SRSS services using either the utrestart CLI or the Admin GUI.
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:
Note - If a registered policy is in place, use the insert_token key instead of the token key, which is not globally unique. |
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:
b. For a username-based mapping, use entries of the form:
c. For a combined mapping, use entries of the form:
A sample line for this file would look like the following:
Note - Tokens for NSCM and authenticated smartcards have the form auth.<username>. These tokens cannot be affected by AMGH. Use the username key instead. |
1. To disable AMGH configuration for a group, run the following command:
2. Do a cold restart of the SRSS services using either the utrestart CLI or the Admin GUI.
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.