This is part six of the “Making VDI Work” blog series by Leostream CEO Karen Gondoly. Click here to read part five “Choosing the Ideal VDI Hosting Platform“, part four “How to Mobilize Your Workforce with VDI and Hosted Resources“, part three “Choosing A Display Protocol“, part two “Things to Consider About Client Devices“, or part one “How to Design the Ideal VDI or Hosted Desktop Solution“. 


Fall is in the air here in New England, and it’s peak leaf-peeping time. Before we get too distracted by the splendor of nature, let’s take some time to discuss the next portion of our VDI architecture diagram, authentication.

 

fall-1072821_1920.jpg

 

User authentication comes into play not only on the remote operating system, but at the beginning of the chain when users log into the connection broker that manages your hosted desktop environment. That makes your authentication systems the first line of defense regarding who has access to your hosted resources.

 

In this day and age, you need secure and reliable systems to confirm your user’s identity. When selecting what systems to use, look at a combination of what you already have in house and what your users ultimately need to connect to.

 

Authenticating down the chain

User authentication occurs in a number of places in a hosted desktop environment. First, there is your connection broker. It needs to authenticate the user in order to identify and authorize them with access to the correct hosted resources.

 

When the user requests a connection to one of their hosted resources, a second level of authentication may occur. Here, the display protocol may want to authorize the user to connect the display protocol’s client to its server.

 

Finally, there’s a third level of authentication that occurs at the user’s desktop. In this last step, the operating system determines if the user is allowed to log into the remote desktop, itself.

 

Given that authentication occurs in so many locations, ensure that you configure systems that make the login as seamless as possible for your users, while ensuring security.

 

What are some authentication options?

The bottom-left box of our standard architecture diagram, shown in the following figure, lists just some of the systems available for authenticating users.

 

 

diagram-2.png

 

When it comes to what you likely have in house, by far the most common mode of authentication validates the user’s identity – in the form of a username and password – against a Microsoft Active Directory (AD) authentication server. Depending on your organization, however, Microsoft AD may not be the only authentication server in play.

 

If users connect to Linux desktops, you may need to authenticate them against a NIS server. Or, you may have a home-grown solution based on OpenLDAP. Ultimately, the types of remote resources you offer to your user may require you to use a mixture of these authentication servers.

 

Username/password authentication classically relies on something the user knows. Depending on the security required in your environment, you may also want your authentication system to request something your user has. In that case, deploy a multi-factor authentication (MFA) system, in the form of tokens, smart cards, proximity cards, or biometrics.

 

When going down the MFA route, consider if your users already use a system, such as a proximity card, to enter their office building or access other resources. If so, is that a system they can also use to access their remote desktops? Keep in mind that one of the keys to any hosted desktop environment is to keep the end-user experience simple and seamless.

 

For example, they should never need to enter a password more than once. And, if the desktop operating system requires a smart card and PIN to log in, then the user’s smart card reader needs to be redirected from their client device to the remote desktop.

 

Key take aways

When it comes to authenticating users, here’s a few things to remember.

  1. Keep in mind any corporate standards that you need to take into account, whether it be Active Directory, NIS, RSA tokens, etc.
  2. Make sure you know, up front, if you need to design in support for multi-factor authentication.
  3. Ensure that all steps in the hosted desktop login work seamlessly with any and all authentication systems you decide to use.
  4. Do your best to avoid the most common end-user complaint, which is the lack of single sign-on to their hosted resources. Make sure you architecture your hosted desktop environment so user enters their credentials once, to access their offered resources, and never again. This may mean using SAML, finding a display protocol that includes a server component that handles SSO, providing USB pass-through for smart card readers, etc


And, with that, we have just one issue of our “Making VDI Work” series left. Next, we’ll talk about a subject that is near and dear to my heart, the connection broker that brings together all of the other pieces of your virtual desktop environment.