But most of the needed functionality already exists under the hood in the SRSS 4.2 Administration GUI. The needed text strings can already be found elsewhere on the page. If you feel adventurous, you can add the missing checkbox yourself and it will work.

To do this:

Disclaimer

All changes to product files described here are unsupported and done at your own risk! Be sure to create backup copies of files before changing them.

Also beware that these changes could be overwritten by a patch – in the (unlikely) case that we release a patch for the Administration GUI without this feature.

Update: The latest update of SRSS 4.2 now supports (well, mostly) smartcard-based hotdesking for OVDC (the new name for SDAC).

Nevertheless hotdesking capabilities are an important feature of the Sun Ray system. So how can SDAC participate?

Answer 1: NSCM

The simplest solution to be able to hotdesk Sun Ray sessions to and from an instance of SDAC is to use NSCM. This has a few restrictions:

It works only on Solaris. Not much of a restriction, if you are running SRSS on Solaris already, but a significant problem, if you are using Linux.

KioskMode and NSCM are a poor fit, as every user must authenticate on UNIX in order to get session access. No problem, if your users have a UNIX login account and are logging into a regular UNIX session anyhow.
But if you are using Kiosk Mode, then requiring UNIX authentication first is a poor fit.
Even if you can set up PAM to make NSCM use a different authentication source (for example ActiveDirectory), there is no single sign-on: the user will have to authenticate again within your Kiosk Session.

NSCM is an all or nothing decision for non-smartcard sessions. If you enable NSCM, it applies to all non-card sessions. You can't disable it selectively, for example when you use token-specific kiosk policy.

NSCM is slightly less comfortable than smartcard-based hotdesking. When you hotdesk a NSCM session, you need to enter both your user name and password. With smartcard-based hotdesking, you only need to enter your password to unlock the screen. And you can use AMGH to preselect a username even on initial login.

If you are not affected by these restrictions or can live with them, then NSCM is clearly the method of choice to obtain sessions that can be hotdesked to SDAC.

Answer 2: Token Aliasing

What if NSCM is not an option, because Kiosk Mode is being used, SRSS is running on Linux or your users can't remember their user names?

In that case you can use a lesser known features of SRSS: token aliasing.

Token aliasing comes at the cost of added administrative effort. It requires that only registered tokens are allowed access. This means that every smartcard, every DTU used for non-smartcard access and every SDAC instance (more exactly: profile) must be registered in the Sun Ray data store, before it can be used for Sun Ray sessions. This burden can be offloaded to your users, by enabling self-registration functionality when configuring registered token policy. Or it can be integrated with a corporate database of tokens, by using the ATI feature (see the ut_ati_script_interface(3)man page for more information). But neither of these will create aliased tokens for you - that will require manual intervention by an administrator.

When you configure two (or more) tokens as aliases of each other, all the aliased tokens access the same session. Every smartcard is associated with a unique token, as is every DTU and every SDAC profile. (The tokens for the latter two are called pseudo-tokens.) So if you configure a SDAC pseudo token as an alias of a smartcard token, then a specific SDAC profile can be used to access sessions bound to this smartcard. In other words, you can hotdesk your card session to SDAC (with this profile) and vice versa.

As you probably noticed this means that an SDAC profile can access only one predetermined smartcard session. This is good for security - the session bound to Alice's smartcard can only be accessed using Alice's SDAC profile, but not using Bob's profile. But it also means that you can't use SDAC to quickly access an arbitrary session from any client. Bob's boss can't borrow Bob's laptop to get to his session, as he most likely has no registered profile there.

There is one pitfall with aliasing: if more than one aliased tokens are connected at once, only one of them can get access to the session. In older releases of SRSS, this resulted in session ping-pong: the second token that connects takes over the session from the first. This causes the first DTU to restart, present its token again, and take back the session. Now the second client restarts and everything repeats itself until one of the clients is disconnected.

Fortunately the 'RHA' hotdesk security feature, introduced in SRSS 4.1, fixes this problem: now the user can only take over a session for her token after authenticating to the RHA session lock. When she does this, the first client will restart, but will only display the session lock and wait for the user to come back to that location. If you like ping-pong, you can still get the old misbehavior by disabling RHA.

The pitfall that remains, even with RHA, concerns Kiosk Mode: as there is no authenticated UNIX user, no RHA authentication can take place. The session takeover protection still applies though, so if the user left his card inserted in a DTU, he will be unable to get to his Kiosk session from his aliased SDAC profile. Of course with traditional smartcard hotdesking you also don't get to hotdesk, if you forget your card elsewhere.

And how can token aliasing be set up?

By now you are probably itching to learn how you can configure token aliases.

If you aren't, why are you still reading?

Keep in mind though, that use of token aliasing is only suitable, if 'registered token only' policy can be used in your deployment. And if NSCM works for you, you can save all this administration effort.

The approach I outline here is to start with unaliased registered tokens, delete one of them from the Sun Ray Data Store and reregister it as an alias of the other. I recommend to start with both tokens registered, so that you can leave the task of figuring out the token identifier to the initial registration process, for example to self-registration. Alternatively you can obtain smartcard token identifiers by using a token reader and derive pseudo tokens from the desktop identifier (see the utdesktop(1M)man page or the Desktop Units tab in the Sun Ray administration GUI).

To make a SDAC pseudo-token an alias of another token using the Sun Ray administration GUI:

Go to the Tokens tab

Find the SDAC pseudo token for the user. An SDAC pseudo token id has the form pseudo.<32 hexadecimal digits>, for example pseudo.d98765f12345f23b697cfd9d072786b7.

Click on the token ID to go to the pseudo.d98765f12345f23b697cfd9d072786b7- Token Properties page.

Select the pseudo token ID and copy it (to the clipboard).

Check that there are no sessions for this token (Advanced section). If there are sessions, terminate them.

Go back to the Tokens page.

Place a check mark on this pseudo token to select it and click Delete to delete it.

Find the smartcard token for the same user, for example Payflex.500abcd000000100.

Click on the token ID to go to the Payflex.500abcd000000100 - Token Properties page.

Click the New... button on the Alias Tokens table (Advanced section) to open the New Alias Token for Payflex.500abcd000000100 page.

Select Enter token identifier manually: and paste the pseudo token into the token id field (from the clipboard).

Click OK.

To do the same using the command line (assuming both tokens have the name 'Barfurth'):