You might have noticed our announcement last week on XenApp 5 Feature Pack. With all of its great new features and functions, it’s easy to see the many cost savings opportunities it brings. One of these is the new freedom that customers get with Single sign-on.

Single sign-on is a XenApp Platinum edition feature. With it, you can enable Single sign-on for any hosted application you deliver – that is, apps that run on the server. Now, with XenApp 5 Feature Pack, you can also use it at the endpoint without having to purchase additional licenses at a cost of $150 per concurrent user. So, as an example, if your company has 3000 users who use XenApp and you bought 1000 XenApp Platinum licenses, with the new licensing policy change in Single sign-on, you can use it for all the 3000 users and for their end point use as well. This saves you from buying additional 2000 licenses. On top of those cost savings, it can potentially reduce password related helpdesk costs by 20-30% and increase user productivity (since they won’t be calling the helpdesk about a frozen password or locked account). But Single sign-on isn’t all you can do with this technology set.

First, as a best practice, you should deliver any password-protected application as a hosted application. Why? The first time the user tries to access any password protected application, Single sign-on will ask to store their credentials for that application. The user provides their credentials via the encrypted connection and it is stored in an active directory store or in an encrypted store. Simple enough. But here is where the magic begins.

You configure the application to ask the user to change their password after the first logon. This is standard practice in your high security organization, right? (wink wink) Normally the user would change their password by re-sending the password over the connection, not once, but twice to verify that it’s correct. So, if there was a key logger on their side the new password has just been compromised even before it is accepted by your system as the new password. But with Single sign-on, this problem is eliminated. It can be configured such that whenever the application asks the user to change their password, Single sign-on will automatically respond with a new cryptic password that matches policies that you have set. And since single sign-on is doing it in the data center, then there’s no way a key logger on the users device can capture it.

Another thing is that since single sign-on changed their password, the user doesn’t know their application password anymore, nor do they need to because single sign-on will provide it to the application anytime they need access. But don’t be worried – if you need to cut off their access, you can be confident that shutting down their active directory account will do the job because if they can’t access the system, they can’t access the password via single sign-on. With manual methods of logon, they would still be able to access the application with their application password using someone else’s AD credentials. With single sign-on in XenApp, this problem is eliminated. This is called “maintaining the login chain”. Basically, you ensure that the user that logged into the system is the same user that logged into the application. Great for compliance purposes.

Up to this point I’ve been talking about hosted applications. I did mention that XenApp 5 Feature Pack now adds the ability to use single sign-on at the end-point. This is a great solution when you have a password protected application that isn’t hosted on XenApp. Maybe you have streamed it to the physical or virtual desktop. You get the same benefits of single sign-on. The only difference is that you’re not protected from key loggers except from virus software and such. This is why I say that the best practice is to host and run any application that requires a logon from your XenApp servers. If you still need to do it at the desktop, the good part is that single sign-on still maintains the login chain and it still automatically changes passwords to make sure that they meet your organizational standards.

Now, as soon as I even mentioned single sign-on, you were probably thinking about that old “keys to the kingdom” argument. It’s a valid one. But when implementing single sign-on you’ve got to do some things differently. First, using single sign-on means that you simplify your users’ life by taking away their need to remember all those application passwords (or write them down on a post it note somewhere). This is just the proof you need to force users to create a stronger domain password via AD password policies. In addition, single sign-on with XenApp also lets you configure whether users have to prove who they are by logging in again before automatically logging them into their application.

And if you’re really paranoid (which you should be), you can add multi-factor authentication (e.g. RSA Secure ID, Secure Computing Safeword, SmartCard authentication, etc.) to your primary credentials. Yes, multi-factor authentication can be a bit cumbersome, but you just made life easier for them. Surely a trade-off is in order. And since multi-factor authentication such as token-pin combinations or Smartcards are pretty much useless to key loggers (they use changing numbers or digital certs), you’re much better off than having users enter every single application password for what they need to access.

Single sign-on with XenApp also includes self-service password reset (SSPR). With SSPR, if your users get locked out of their domain account, you can let them securely unlock it by answering security questions that you set up. You can customize the questions and users personalize the answers when they set up the service. You can then enable self-service password reset and account unlock from the Windows logon screen or even from XenApp Web interface. This feature is all about reducing helpdesk calls and increasing user productivity. Good stuff for sure, and best of all, you can use SSPR independently of whether you choose to use single sign-on for your applications.

So, just to boil this down, single sign-on reduces helpdesk costs, increases password strength, increases application security, and enhances compliance. Your ability to use single sign-on in your own environment will vary on a number of factors from company culture to the level of paranoia of your security architect to whether you’re the CIA. However, if you can use it, you should – even if it’s just for the self-service password reset and account unlock feature. In these economic times, anything that can save you money is worth checking out.

Want to learn more? Also, check out Stay tuned for weekly blogs on XenApp 5 Feature Pack. As always, let us know your thoughts, questions and feedback below.

This post is part of a multi-part series on XenApp 5 Feature Pack: