Monday Aug 09, 2010

OVDC + Smartcards - a Web UI hack

As already reported on ThinkThin, the Oracle Virtual Desktop Client now supports use of smart cards for hotdesking. This way you can now access the session from your Sun Ray from your laptop or PC, without having to resort to the configuration tricks I described a while back.

To use this feature, you first need to apply the recently released SRSS 4.2 patch (rev -03 or later) to your Sun Ray server. Then you also need to enable smartcard access for OVDC.

Unfortunately you need to read the fine print to discover that you can only enable or view this policy setting using the Command Line interface.

There are several technical and procedural reasons, why we could not include an update to the Sun Ray Administration GUI with the recent update.

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:


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.

Edit the file /opt/SUNWut/webadmin/webapps/ut/jsp/advanced/Policy.jsp:

  • Find the comment that reads
    <!-- no support for enabling softclient access with cards yet - just omit control -->
  • Replace it with the following:
    <ui:property id="softclientCardProp"
            <ui:checkbox id="softclientCard_editable"
                            onClick="disableElements(); toggleEditButtons();"

After applying this change, restart the Administration GUI using the command

# /opt/SUNWut/lib/utwebadmin restart
and reconnect to the Administration UI in your browser.

Tuesday Sep 29, 2009

Odd Sizes

Starting from SRSS 4.1, the Sun Ray Xnewt X server supports the XRandR extension, which allows resizing your desktop while the session is running. This is particularly useful, if you often hotdesk among Sun Ray DTUs with monitors of different sizes.

Bob even has created a utfit script, which you can use automatically fit your desktop size to the new screen size on hotdesk (needs to be run via utaction on connect).

But the set of sizes any given Sun Ray session can be resized to is limited. And this selection of sizes doesn't really have anything to do with the currently used Sun Ray and its monitor. If the monitor is small, you may be able to something larger than your monitor and will get scan+pan behavior. If the monitor is large, its size may simply not be available. Instead the sizes that are offered depend on the initial size of your desktop - or more precisely the size of the X server canvas.

When a Sun Ray Xnewt X server is started, it creates a frame buffer that best fits the display of the currently connected DTU. Only if this monitor is very small, a certain minimum size will be reserved. This size is then seen as the initial size of the desktop. As the frame buffer can't be grown later, this size then becomes the limit for future resizing: you can shrink your desktop and enlarge it again, but only up to the original size. XrandR will offer you a set of standard sizes, but these must be smaller than the starting size in both dimensions.

This is particularly troublesome, if you frequently move between screens where neither is smaller than the other in both dimensions. Myself I usually use a 1600x1200 20,1" monitor at work and a 22" 1680x1050 monitor at home. Now if I start my session at work (1600x1200), I can't resize it to fit my home screen, as 1680px is wider than the frame buffer. But if the session is started at 1680x1050, then I can't resize for my work screen either, as 1200px is taller than the 1050px frame buffer :-(

utxconfig to the rescue

To solve this problem, you can control the size of the X server canvas using the utxconfig command. If you specify a resolution (i.e. a size), a newly started X server will create a frame buffer that can hold this size. In my case, I used

  $ utxconfig -r 1680x1200
to specify an odd size, which fits no real monitor exactly. The important property of this choice is that it is at least as large as the pixes dimensions of all the monitor I regularly use. After issuing this command and getting a new X server, I can see that XrandR now allows me to resize my desktop to all the sizes I need:
  $ xrandr
   SZ:    Pixels          Physical       Refresh
   0    640 x 480    ( 180mm x 135mm )
   1    800 x 600    ( 225mm x 169mm )
   2   1024 x 768    ( 288mm x 216mm )
   3   1152 x 900    ( 325mm x 254mm )
   4   1280 x 1024   ( 361mm x 289mm )
   5   1400 x 1050   ( 395mm x 296mm )
   6   1440 x 900    ( 406mm x 254mm )
   7   1600 x 1024   ( 451mm x 289mm )
  \*8   1600 x 1200   ( 451mm x 339mm )
   9   1680 x 1050   ( 474mm x 296mm )
   10  1680 x 1200   ( 474mm x 339mm )
  Current rotation - normal
  Current reflection - none
  Rotations possible - normal 
  Reflections possible - none
I need to adjust the size right after initial login, but the utfit script will do even that automatically. And the benefit is well worth the tiny effort anyhow.

Update: the utxconfig command binds the chosen size to your token and stores it in the Sun Ray Data Store. Thus the command needs to be run only once within a failover group. The setting applies on all servers of the group and stays active until you run utxconfig again to change it. But if you occasionally use multiple tokens, you have to set up the session size separately for each one.

Thursday Sep 24, 2009

Hotdesking sessions to and from the Sun Display Access Client

The initial release of the Sun Desktop Access Client (SDAC) does not participate in the smartcard-based hotdesking that is typically used with Sun Ray Desktop Units (DTUs).

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.

So how does token aliasing help with SDAC hotdesking?

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:
  1. Go to the Tokens tab
  2. Find the SDAC pseudo token for the user. An SDAC pseudo token id has the form pseudo.<32 hexadecimal digits>, for example pseudo.d98765f12345f23b697cfd9d072786b7.
  3. Click on the token ID to go to the pseudo.d98765f12345f23b697cfd9d072786b7- Token Properties page.
  4. Select the pseudo token ID and copy it (to the clipboard).
  5. Check that there are no sessions for this token (Advanced section). If there are sessions, terminate them.
  6. Go back to the Tokens page.
  7. Place a check mark on this pseudo token to select it and click Delete to delete it.
  8. Find the smartcard token for the same user, for example Payflex.500abcd000000100.
  9. Click on the token ID to go to the Payflex.500abcd000000100 - Token Properties page.
  10. Click the New... button on the Alias Tokens table (Advanced section) to open the New Alias Token for Payflex.500abcd000000100 page.
  11. Select Enter token identifier manually: and paste the pseudo token into the token id field (from the clipboard).
  12. Click OK.
To do the same using the command line (assuming both tokens have the name 'Barfurth'):

First determine the involved tokens, for example:

  # sdactoken=`utuser -ln Barfurth | sed -n 's/\^\\(pseudo\\.[0-9a-f]\\{32\\}\\) .\*/\\1/p'`
  # echo $sdactoken
  # cardtoken=`utuser -ln Barfurth | sed -n 's/\^\\(Payflex\\.[\^ ]\*\\) .\*/\\1/p'
  # echo $cardtoken
After obtaining the tokens, delete the existing unaliased registration and create an alias instead:
  # utuser -d $sdactoken
  # utuser -ai $cardtoken $sdactoken

Friday Aug 21, 2009

Sun Ray "YUV" Icon Modernization

Some new features in SRSS 4.2, like client authentication and support for the Sun Display Access Client (SDAC) required new server policy (aka "YUV") icons. The server needs a way to tell you that it is configured to reject SDAC connections or that it doesn't accept your client keys.

So a while back I got together with Matthias to design the missing icons, but after looking at the existing YUV icons, we couldn't get ourselves to create more of the same. Instead Matthias set out to create a new theme for these icons. To show you why, here are some examples of old icons and their new counterparts:

Old IconNew IconMeaning
Old Insert Card Icon: Sun Ray 1, tiny white card, thick green arrow pointing from card to DTU, all on purple beveled button.New Insert Card Icon: Smart card at entry to slot. Status code 60.Insert Card (No access without card)
Old Card Error Icon: Sun Ray 1 with card, yellow triangle with exclamation mark, crooked black arrow pointing from triangle to DTU, all on purple beveled button.New Card Error Icon: Smart card with question mark. Status code 63.Card Not Recognized
I wonder what users who have never seen a Sun Ray 1/1G in its purple stand have been thinking about these tilted squares with the purple triangle...
Old No Entry Icon: Red circle with white horizontal bar ('no entry' traffic sign) on purple beveled button.New No Access Icon: Stylized screen with cross in the middle. Status code 46.No Access for this token due to server policy.


('No Entry' sign, as above, in SRS5 EA1)

No Access For SDAC Icon: Stylized window on desktop with cross in the middle of the window. Status code 47.No Access for SDAC due to server policy.

The new icons:

  • Have a consistent style, but don't imitate the firmware OSD.
  • Should blend into the DTU background almost seamlessly
  • Have status codes for better supportability. No more wondering why SDAC is reported to show a red ball (that must have been the 'no entry' icon).

To see them all, look at their brand-new documentation. Thanks Paul!

If you have looked at our SRS 5 EA1 release, you may wonder why you haven't seen the new icons. The answer is that they didn't make EA1 - but you will find them in the upcoming EA2 release.

BACKGROUND: Sun Ray Icon Types
SRSS has two kinds of troubleshooting icons:
On Screen Display (OSD) Icons
These icons are produced by the DTU and inform about DTU status or error conditions. The DTU overlays these icons over the usual display contents sent by the server. These icons were modernized serveral releases of SRSS ago.
Server Policy ("YUV") Icons
These icons are sent by the server to signal why a DTU does not get normal session access. They are called "YUV" icons, because the server sends icon data in YUV format to the DTU. This does not require a regular session with a full X server. Instead a low-footprint yuvfile process sends the pixels directly to the DTU. This program has much less sophistication than the SRSS Xnewt server, so features like NAT traversal or detection of lost pixels don't work for YUV icons.

Friday Jun 26, 2009

Using different Kiosk Sessions for different tokens

Original Sun Ray Kiosk Mode or its predecessor CAM only allowed one Kiosk configuration that applied to all kiosk sessions on a server. Since SRSS 4.1 there is a little known feature that allows adding additional kiosk configurations and selecting one them based on the token.

Unfortunately configuring this feature currently requires using the utkiosk and utkioskoverride tools on the command line. This probably is the main reason why add-on solutions to do the same, like Daniel Cifuentes's Meta-Kiosk are still popular.

For those not afraid of the command line, here is a short how-to

  1. Create a kiosk session configuration.

    You first need to create a file (named UserSession.conf here, but you can freely choose a name) containing your kiosk session configuration. Of course you can simply create it as a text file, after reading the session.conf(4) man page. But if you prefer to use the SRSS Web Admin GUI for this step, you can do it as follows:

    • Configure the session settings on the Edit Kiosk Session page
    • If you are using the JDS desktop session, add the applications you want to see in the menu.
    • Save your changes
    • Get a root shell on one of the servers and use it to save the configuration to a file:
      # cd  # Make sure your are in a reasonable directory to store your configurations
      # PATH=${PATH}:/opt/SUNWut/sbin    # Save yourself (and me) some typing
      # utkiosk -e session -s > UserSession.conf
    • If you have configured applications, also save the application list to a file:
      # utkiosk -e session -a > UserSessionApps.list

  2. Store your kiosk session configuration in the Sun Ray data store.

    You now need to store your configuration in SRDS, so it can be used for Sun Ray kiosk sessions. You can store each configuration under a name you choose. This example will use UserSession. Use a name that starts with a capital letter - all-lowercase names are reserved.

    If you don't need an application list, you can simply upload your UserSession.conf file like this:

    # utkiosk -i UserSession -f UserSession.conf

    If you did create an application list, the command looks like this:

    # utkiosk -i UserSession -f UserSession.conf -A UserSessionApps.list

  3. Configure individual tokens to use this kiosk session configuration.

    You now need to assign this configuration to selected tokens. I'll show this here for the imaginary CleverCard.0123456789 card token. You can assign kiosk setting to selected DTUs (when used without a smart card) in the same way.

    • In order to apply special kiosk setting to the token, it needs to be registered (even if you don't use a "registered" access policy). If the token isn't registered yet, you can do this now without leaving the command line:
      # utuser -a "CleverCard.0123456789,localhost,0,John Doe,"
    • Now you can assign the UserSession configuration to the token:
      # utkioskoverride -r CleverCard.0123456789 -s kiosk -c UserSession 
      Note: This will enable Kiosk Mode for this token, even if it isn't enabled globally.

    • If you have stored multiple session configurations, you can view them using:
      # utkiosk -l
      The session configuration is the default kiosk configuration, which is used for all kiosk session that haven't been assigned an override.

Musings about my work in the (virtual) desktop space and whatever else moves me.

Keep on your desktop at all times.

Disclaimer: The statements and opinions expressed here are my own and do not necessarily reflect those of Oracle


« July 2016