The broker's integration with a back-end directory service can play a significant role in many of the decisions regarding how a virtual desktop infrastructure (VDI) environment is deployed in VMware Infrastructure 3 (VI3). In this tip, we'll examine the integration between the connection broker and a commonly-used back-end directory service, Microsoft Active Directory.
In our previous articles, we discussed
Remember that the connection broker receives inbound connection requests and has to validate those requests and select an appropriate hosted operating system (OS) instance for that connection request. Some brokers have the ability to maintain an internal list of user accounts, but most organizations will want to integrate this authentication process into their existing directory service rather than maintain separate user account databases. In many organizations this directory service will be Active Directory, so we'll focus only on Active Directory for the purposes of this article. Please note that Active Directory is typically not the only supported directory service, as some brokers also support Novell eDirectory and generic LDAP directory services.
What to consider
When planning for a VDI deployment, there are a number of items to consider with regards to the connection broker's integration with Active Directory. Some of these items include:
- Authentication to Active Directory in order to perform queries
- Potential passing of unencrypted passwords across the network
- Network traffic to/from Active Directory domain controllers
- Use of Active Directory to determine hosted desktop access or entitlements
The extent to which these items become a consideration during a VDI deployment depend greatly upon the connection broker itself. In a connection broker that uses Lightweight Directory Access Protocol (LDAP) to communicate with Active Directory, most of these items become considerations. By default, Active Directory does not allow unauthenticated LDAP queries; this means that the broker must have some means of authenticating itself to Active Directory. This translates into a service account within Active Directory that must be maintained for the connection broker.
Similarly, depending upon the connection broker, the method that the connection broker uses for authentication may send this service account's password in the clear across the network. Some brokers use LDAP over SSL/TLS to address this issue, but this can introduce additional complexities and dependencies to the implementation.
Other brokers may use Active Directory Application Mode (ADAM) to create a replica of information in the "true" Active Directory hierarchy, plus additional attributes that are specific to the connection broker itself. This has the advantage of not requiring schema extensions in Active Directory.
In either case, network traffic from the connection broker to Active Directory must be addressed. Depending upon the type of broker--in-line versus out-of-band--organizations may be interested in deploying the broker in a demilitarized zone (DMZ). Because the broker needs to communicate with Active Directory, network security professionals will have to open the appropriate ports between the DMZ and the internal network. In many cases, this is LDAP traffic, so TCP port 389 and/or TCP port 636 will need to be opened.
The implementation impact
Finally, the way in which the connection broker actually uses Active Directory will have an impact on the implementation. Consider a broker that uses LDAP to communicate with Active Directory. For authentication, this broker will typically issue an LDAP query to find the corresponding user object in Active Directory. If this query relies upon un-indexed attributes, these queries may end up being very CPU intensive. Fortunately, it appears that most brokers use the sAMAccountName and/or userPrincipalName attributes, both of which are indexed attributes.
Similarly, a broker that uses LDAP for Active Directory integration will typically use group memberships to help determine the hosted desktop(s) to which the user should connect. Determining entitlements -- as they are known by some connection brokers --is a key role for the connection broker, so it's very important to understand how the broker will use Active Directory. Will the broker be able to use all the group memberships, or only the last group membership checked by the broker?
Determining these key points in integrating a connection broker with Active Directory, as well as other back-end directory services, sets the stage for how, and how well, a VDI environment is deployed. In my next article, I'll take a look at other connection broker integration points and how they could affect your VDI deployment
About the author: Scott Lowe has had a lifelong love of computers, dating all the way back to
his first computer, a Tandy TRS-80 Color Computer. He began working professionally in the
technology field in 1994, and has since held the roles of an instructor, technical trainer,
server/network administrator, systems engineer, IT manager, and CTO. For the last few years, Scott
has worked as a senior systems engineer with a reseller, providing technology solutions to
enterprise customers. Scott also runs a virtualization-centric weblog at blog.scottlowe.org.
This was first published in January 2008