Create exceptions for non-smartcard sun ray logins

People use Sun Ray DTUs with SmartCards for mainly two reasons: To enable hot-desking between devices and as an extra layer of security by only allowing Sun Ray logins with a (registered) smartcard. This is easy enough to set up, simply disable non-card access in the Policy section of the GUI or through the utpolicy commandline tool. We register all our smartcards to a certain user and only allow those registered cards access which will also pre-fill the username field of the login mask so even if I knew the password of my teammate, I could not log on as his user unless I also steal his card. This is a pretty common setup.

But the introduction of OVDC softclients (either for PC or Mac or tablets) has made this a bit more complicated. You can of course use a USB cardreader with your laptop but I try to avoid carrying extra stuff when travelling and also the iPad simply does not allow to connect a reader. So what I would like to do is to register certain OVDC clients that I wish to grant access to, even without a SmartCard present. First, set up the policy by selecting to allow non-smartcard access for registered tokens.

vdi01 # /opt/SUNWut/sbin/utpolicy -a -m -r both -u both -k both -g

Now, if you try to connect with a softclient and without a card, you will see an error icon with code 48 like this.OVDC_error_48

You’ll need to register the pseudo-token for this client first. Fortunately, we can see the generated pseudo token in the session view of the GUI (or check the logfile at /var/opt/SUNWut/log/messages)

May 22 12:26:28 vdi01 utauthd: [ID 743192] Worker3 NOTICE: CLAIMED by Registeredxlation.m3 NAME: pseudo.3da017443aa67e6c0baf7ca44df35e86 PARAMETERS: {terminalIPA=, type=pseudo, state=disconnected, cause=insert, doamgh=true, rawId=3da017443aa67e6c0baf7ca44df35e86, terminalCID=MD5.3da017443aa67e6c0baf7ca44df35e86, MTU=1422, tokenSeq=2, firstServer=c0a85471, namespace=MD5, keyTypes=dsa-sha1-x1,dsa-sha1, sw=Oracle:SunRayS1:Darwin:3.1.0, id=3da017443aa67e6c0baf7ca44df35e86, clientRand=Nv85Zyvy5/JD9xP/KXOqARkbmi.58eXiKP6ZXDGcbDW, realIP=0a002a2a, startRes=1152x680:1152x680, useReal=true, event=insert, sn=3da017443aa67e6c0baf7ca44df35e86, rawType=pseudo, clientKeyStatus=autoconfirmed, hw=SunRayS1, initState=1, _=1}
May 22 12:26:28 vdi01 utauthd: [ID 427441] Worker3 NOTICE: CONNECT MD5.3da017443aa67e6c0baf7ca44df35e86, pseudo.3da017443aa67e6c0baf7ca44df35e86, notregistered
May 22 12:26:30 vdi01 utauthd: [ID 665514] Worker3 NOTICE: MTU = 1422
May 22 12:26:30 vdi01 utdtsession: [ID 702911] Add (14,pseudo.3da017443aa67e6c0baf7ca44df35e86,special)
May 22 12:26:30 vdi01 utauthd: [ID 622882] Worker3 NOTICE: SESSION_OK pseudo.3da017443aa67e6c0baf7ca44df35e86

Copy the string that starts with pseudo to your clipboard and navigate to TOKENS and click on NEW. Paste the pseudo token, enter a username and you are good to go. From now on, this soft client will be allowed create sun ray sessions.
Instead of creating a new token you could also add this as a new alias for the existing smartcard token. And I think that previous versions worked in such a way that a session was being displayed at the DTU or soft client that last presented a token. (meaning I could forget to remove my smart card at the office but transfer that session to my OVDC client with the alias token from home). With 5.4 this does not work and is also clearly documented in that way (error 64). Also, this is not really an issue when using the VDI kiosk script because it will take care of logging in with the same username from different sessions. But when you use “regular” sessions to the host solaris or linux this would be annoying because you would create a second user session which usually is not handled very well by window managers and/or applications.

Here is another screenshot of the soft client with the pre-filled (and not changeable) username field.OVDC_VDI_login

Leave a Reply

Your email address will not be published. Required fields are marked *