QVD comes with user management built into the database, and adding them through the Web Administration Tool is really simple. However, for larger organisations, the chances are you’ll already have some kind of central authentication in place, commonly LDAP or Active Directory. In the first of a two part series, let’s look at getting your system authenticating against an LDAP server first, and next week we will look at AD.
Testing Your LDAP Server
The first thing you will need to do is ensure that the your node server can successfully connect to your LDAP server from the command line. Doing this first will ensure that you don’t run into problems that may be hard to identify later. Make sure you have the ldap-utils (Ubuntu) or the openldap2-client (SLES) package installed as it provides a series of useful tools for communicating with an LDAP instance.
ldapsearch -xLLL -H ldap://example.com -b "dc=example,dc=com" cn=admin cn
Of course, point the host (after the -H flag) to your own LDAP server (and change ldap to ldaps if you have a secure setup) and alter the search base (-b) as is appropriate for your setup. This should return something similar to the following:
dn: cn=admin,dc=example,dc=com cn: admin
At this point you should be satisfied that read access to your LDAP server is possible from your QVD node and you are ready to continue.
Basic LDAP Configuration
Next you will need to install the LDAP Authentication Plugin on your node server. For Ubuntu, that will mean installing perl-qvd-l7r-authenticator-plugin-ldap, and for SLES 11 perl-QVD-L7R-Authenticator-Plugin-Ldap, so go ahead and install that using apt-get or zypper.
That done, you will need to configure your QVD node to authenticate against LDAP. Use the administration tool qa for each of these settings as the QVD database takes precedence over /etc/qvd/node.conf file and will ensure that all nodes will see the changes. Enclose settings in single quotes to save yourself the trouble of having to escape all those brackets and other special characters that an LDAP schema throws up.
qa config set l7r.auth.mode='ldap'qa config set auth.ldap.host='ldap://example.com:389'
qa config set auth.ldap.base='ou=People,dc=example,dc=com'
qa config set auth.ldap.filter='(&(objectClass=inetOrgPerson)(cn=%u))'
Let’s walk through some of those options. simply tells QVD that you wish to authenticate against LDAP, whilst points it to your LDAP server. Next you want to tell QVD where the base of the Directory Information Tree, or DIT is, and that is exactly what you do with step does. Next 
you tell QVD how you would like to filter against the database, in this instance by inetOrgPerson (your users) and using their common name, assuming that this is their username. Finally you instruct QVD to use the LDAP scope of sub which permits it to look down the subtree until it finds the cn.
That done, restart the l7r service (service qvd-l7r restart) and QVD is ready to start authenticating against LDAP, it’s that simple.
Auto Provisioning of Desktops
However, this method is not quite the full picture and perhaps a little simplistic for a real world example, as you will still need to create each machine for each user and it’s unlikely that this is desirable. So QVD comes with an automatic user provisioning plugin that creates desktops for your users on the fly when they authenticate successfully against LDAP.
You’ll need to install the plugin, again with your package manager. It’s called perl-qvd-l7r-authenticator-plugin-auto for Ubuntu, for SLES, install perl-QVD-L7R-Authenticator-Plugin-Auto. Again with the administrative tool, make the following changes:
qa config set l7r.auth.plugins='auto,ldap'qa config set auth.auto.osf_id=1
tells your QVD installation that you with to provide auto provisioning (along with LDAP), whilst will configure your install to use OSF id 1 which you should adjust accordingly. Restart the l7r service and the next time a user successfully authenticates against your LDAP server, QVD will create a VM for them using the OSF you have set, and and serve it to them seamlessly.
Restrictions of QVD and LDAP
QVD’s LDAP implementation provides an extremely powerful tool for enterprises to roll out desktops to their users quickly and painlessly, particularly in the event that you already have an LDAP server up and running and populated with your user data. However, we were very careful to make sure that we don’t have any negative effects on your existing systems, so the QVD software is not able to make any write access to your data store. This means that the user management inside QVD Web Administration Tool becomes read only, and adding and changing credentials therein will have no effect. Data will be stored inside the QVD database but since it is configured to authenticate against LDAP, that data is effectively ignored by the system. This is absolutely by design, we couldn’t take the risk that the QVD would interfere with existing LDAP tools that you already use, and it is to these you will now need to turn to manage your users.
Troubleshooting
If you run into trouble, ensure that you can authenticate against your LDAP server directly from the command line in your QVD node, as described above. Also take a look at the log file /var/log/qvd/qvd.log – it will contain any authentication errors that have happened.
For a man page style list of all available AD and LDAP configuration settings, please refer to the perldoc of the QVD LDAP plugin as follows:
/usr/lib/qvd/bin/perldoc QVD::L7R::Authenticator::Plugin::Ldap
Active Directory
Next time we will take a look at Active Directory. AD is of course a very common directory service amongst enterprises the QVD offers full support for it along with LDAP. Inspired by LDAP, configuration is somewhat similar and, like the QVD LDAP setup, it’s easy when you know how.
For further information including a full list of all the LDAP options, please refer to our administration guide or get in touch.