Following on from last week’s post on authenticating the QVD against LDAP, this week we turn to Active Directory, another common single sign-on authentication service provided by companies. Since AD makes use of Lightweight Directory Access Protocol (LDAP) versions 2 and 3, the process is pretty similar.
Testing Your Active Directory Server
As with LDAP, it’s probably a good idea to make sure you can connect to your AD server from the command line of your QVD node before you begin any configuration changes. This will narrow the scope of your troubleshooting should you run into problems down the line. To do you will need to 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. That done, run the following command from your QVD node command line:
ldapsearch -LLL -H ldap://example.com:389 -b ‘dc=example,dc=com’ -D ‘EXAMPLE\jdoe’ -w ‘password’ ‘(sAMAccountName=jdoe)’
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) and account name as is appropriate for your setup. This should return something similar to the following:
dn: CN=John Doe,CN=Users,DC=example,DC=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: John Doe sn: Doe givenName: John distinguishedName: CN=John Doe,CN=Users,DC=example,DC=com instanceType: 4 whenCreated: 20130417152557.0Z whenChanged: 20130417152612.0Z displayName: John Doe uSNCreated: 20553 memberOf: CN=Users,CN=Builtin,DC=example,DC=com uSNChanged: 20563 name: John Doe objectGUID:: r7URCgubR0GGxTnxDQkdTg== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 130106859571806640 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAAbhS4Tz7BzIZCZsndUgQAAA== accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: jdoe sAMAccountType: 805306368 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=example,DC=com dSCorePropagationData: 20130417152557.0Z dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 130106859725400390
So once you have successfully logged into the AD server and retrieved the account information for a user on your domain you are ready to continue.
Basic Active Directory Configuration
As with the LDAP configuration, you will need to install the LDAP Authentication Plugin on your node server to connect to Active Directory. For Ubuntu, that will mean installing perl-qvd-l7r-authenticator-plugin-ldap, and for SLES 11 perl-QVD-L7R-Authenticator-Plugin-Ldap. These should be available through your package manager since you installed the node server.
That done, you will need to configure your QVD node to authenticate against Active Directory. Use the administration tool qa for each of these settings and remember to enclose all values inside single quotes to prevent any shell expansion issues with brackets and the other special characters.
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.scope='sub'
qa config set auth.ldap.binddn='CN=Administrator,CN=Users,DC=example,DC=com'
qa config set auth.ldap.bindpass='password'
qa config set auth.ldap.filter='(sAMAccountName=%u)'
l7r.auth.mode simply tells QVD that you wish to authenticate against an LDAP server (Active Directory in this case), whilst will point to your LDAP server. You may wish to use ldaps if you are using SSL.
The LDAP base tells QVD where in the directory tree to begin searching and setting the scope to sub tells it to look anywhere below the base. The Bind DN will be a user on the AD server permitted to search the directory within the defined search base, in this instance the Administrative user. You may well opt to add another user for this purpose to increase security. The bindpass key is then used to authenticate this user.
Finally you tell QVD to match the user’s name against sAMAccountName 
which, as you can see in the above example, is the logon name for Windows user. If AD finds a match against this user, it will authenticate the user to access the QVD.
Once you have configured your LDAP settings, restart the l7r service (service qvd-l7r restart) and QVD is ready to start authenticating against Active Directory.
Auto Provisioning of Desktops
Whilst the above setup will allow you to authenticate users against Active Directory, you will still need to create a machine for each user in the directory. So QVD comes with an automatic user provisioning plugin that creates desktops for your users on the fly when they authenticate successfully against LDAP or Active Directory.
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. Make the necessary changes with the qa tool:
qa config set l7r.auth.plugins='auto,ldap'qa config set auth.auto.osf_id=1
The plugins setting tells your QVD installation that you wish 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 Active Directory
It’s important to note, as with the LDAP configuration, that QVD’s Active Directory support is read-only. QVD is not able to make changes to your Active Directory, so once you’ve enabled AD support, all user and password management must take place therein. With the notable exception of the QVD WAT admin user, changes or additions to user accounts and passwords in the QVD database will be ignored by the system. This is by design, we couldn’t take the risk that the QVD would interfere with an existing Active Directory setup tools that you already have in place.
Troubleshooting
If you run into trouble, ensure that you can authenticate against your Active Directory 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
Also refer to our administration guide for additional information and feel free to contact us if you need any assistance.