The X Factor for Maintaining a Successful Deployment

Several months ago, we got a distress call from a customer that had rolled out disk encryption to a number of endpoints. Following the deployment, OneSign had ceased to function as the encryption program took over the GINA preventing users from tapping their badge to login. The change to make the two programs coexist properly was contained in our knowledge base and it took about 20 minutes on the phone with the customer to help them through the changes that needed to be made to remedy the situation.

I often have conversations with customers about the level of effort that is required to support OneSign once it is deployed. We usually talk about the resources that are required to work on testing new application profiles or changes to existing profiles, but if you back up one level, you will see the X factor.

Having visibility and co-ordination across the groups that are able to make changes to the environment is a must. Security, networking, desktop team, applications guys… Very often we see a number of different groups that are able to implement changes without having a consolidated change control process. In the example above, the group rolling out the disk encryption, was not aware of the OneSign platform so it didn’t do any testing with the agent.

Nobody that I have ever spoken to in IT, likes dealing with these fires. They make IT look bad, makes the end users unhappy with IT and usually derails the 10 other things you were working on. The goal of change control is to reduce these fires significantly by making sure that the people making the changes include all variables in their testing. Where do changes come from that could affect OneSign? Below are a few areas along with examples.

• Desktop team
  • New laptops – Customer purchased laptops with fingerprint readers that did not support OneSign. There are not many we do not support but it is still good to check first.
  • Disk encryption or remote access solutions – Both packages want some control of the authentication at some level. Our knowledgebase contains articles on the ones that we have seen and worked with in the past to have solution that meets the customer needs.
• Applications team
  • Upgrade of an application – Typically this does not break Single Sign-On but it can if there are changes in the UI of the application around login, login success or change password.
  • New applications – It would be a very quick and easy win to roll out an SSO profile with the rollout of a new application to help drive adoption rate.

When we do deployments, we try to emphasize this as much as possible. Here’s a few best practices we like to encourage:

1. If you do have a change control process (such as ITIL), ensure a step is included to ensure OneSign authentication and single sign-on are working correctly
2. Pay particular attention to applications that change the GINA. We have a number of support notes that can be found in the customer center containing best practices for a number of applications
3. If you don’t yet have your process in place, then have the OneSign admin meet with the heads of the other teams to give an overview of the technology. This will get them thinking about OneSign when they come to make changes.

I think we can all agree that with the speed that the world moves these days, our days are crazy enough as is without an out of the blue fire to fight. If you don’t agree, then I am guessing you are the type that enjoys skydiving and running with the bulls…