If you have followed the discussions in the XenDesktop forums, or – even better – if you’ve tried the beta version of XenDesktop, you’ll be aware that it integrates with Active Directory. Indeed, in particular the Desktop Delivery Controller (DDC – the component responsible for brokering end users to their virtual desktops) has a strong dependency on AD, and stores some data in AD that relates to security and determines how virtual desktops discover and communicate with desktop delivery controllers. Several questions have come up on this integration, and on what is actually stored in Active Directory. This post will show in more detail what’s going on under the covers. Just a note of caution: the information in this post reflects the beta release of XenDesktop; however we’re not expecting major changes in this area in the final release.
When you install a DDC server, an “AD set-up wizard” will start towards the end of the installation. When you install the first DDC in a farm, the wizard will ask you for the location of an OU, and will populate it with the data that XenDesktop needs to link up virtual desktops and DDCs, and to secure their communication paths. Whenever you install an additional DDC or remove one, the wizard will also start, and add or remove the DDC-specific information from that OU, although you won’t typically see this, because it happens without the wizard GUI actually popping up. You can also run the wizard manually at any time, it’s installed in the start menu on a DDC, and you can also run it from the command line (c:\program files\citrix\xendesktop server\adsetup.exe; use the ‘rungui’ option to start the GUI wizard).
When the wizard is running for the first time, it asks you to choose an OU for that farm, as shown in the previous screen shot. Every DDC farm needs a separate OU. The OU can be at an arbitrary level of a domain, and the OU does not need to contain the computer accounts for either the virtual desktops or the DDC servers (although it’d be best practice for the DDC servers to live in the farm’s OU). If the user running the wizard has sufficient privileges, they can choose to create a new OU (tick the check box in the wizard). Alternatively, a domain administrator can pre-create an empty OU, and give the XenDesktop administrator running the wizard sufficient delegated privileges over that OU (you’ll need ‘create child’ permissions). In that case, you should select that empty OU in the wizard by using the AD browser, as shown in the example above.
Now let’s look at the data that shows up in the OU after the wizard has completed. The following screen shot shows that the OU contains one security group, one service connection point (SCP), and a container that contains another service connection point object:
The ‘Controllers’ security group is used by virtual desktops to ensure that only authorized DDCs that are members of the farm can broker and control connections (I’ll explain how virtual desktops figure out where to find this security group in a moment). Whenever a DDC invokes one of the web services implemented by the virtual desktop, the VDA (Virtual Desktop Agent, the XenDesktop component that you install on a virtual desktop) will check that the caller is a member of this security group. When you add DDCs in the AD set-up wizard, as shown in the following screen shot, one of the things it does is to add the computer account for the DDC into this security group. Because the OS service that invokes web services on the VDA runs using the NetworkService predefined account on the DDC, the VDA will see incoming calls as using the DDC’s computer account. You need to exercise caution in which computer accounts are made a member of this group, because all VDAs in your farm will trust these computers to control them.
Next, the farm’s OU contains a ‘Farm SCP’. This is an object that contains some markers in the keyword attribute, which define the enclosing OU to be a XenDesktop OU. The keywords include a couple of GUIDs as well as the name of the farm prefixed by XDFarm:, as shown in the following screen shot.
By virtue of being a marker, the farm SCP allows the VDA installer to present a list of farms that the virtual desktop can join: when the installer runs, it searches the global catalog for all SCPs that contain the XenDesktop GUID in their keywords, and lets the user select one of the farms. This results in a registry entry being written to the registry on the VDA, as shown in the following screen shot. The FarmGUID contains the AD GUID of the OU that contains the farm SCP chosen in the installer (i.e. the OU’s objectGUID attribute). You can also set this after installing the VDA, and we’ll provide a group policy template that you can use to set an equivalent registry entry through policies.
If you need to find this GUID, it’s also displayed in the farm’s read-only properties in the AMC, as shown below:
The final piece of information stored in the farm’s OU lives in a separate ‘RegistrationServices’ container. This contains one SCP object per DDC in the farm, and the SCP object’s name is the GUID of the computer object in AD that represents the DDC (in my example, my server called ddc.martinm.local is represented by the DDC$ object in the Computers container, and that object’s objectGUID attribute contains the value 84d879b8-…). This is the second piece of data that the AD set-up wizard writes to the OU when a new DDC is added. The SCP again contains a number of GUIDs and other information in its keywords attribute that mark it as a XenDesktop server SCP; this is similar to the farm SCP. In addition, it also contains the URL and binding information of a ‘registration’ web service that runs on every DDC, and which VDAs use to register themselves with the farm. The AD set-up wizard creates the SCP for each DDC and gives each DDC write access to its SCP. Every time the DDC starts it validates that the information in the SCP is still accurate, and updates it if necessary (e.g. if you change the TCP port used by the DDC).
Using this information, a VDA on a virtual desktop gets linked into the farm as follows: the VDA starts up, reads the farm OU GUID from its registry. It then attempts to bind to AD through LDAP, and checks that the OU is indeed a valid XenDesktop farm OU (by checking the farm SCP). It then enumerates all registration service SCPs by querying AD for all SCPs with the right keywords (GUIDs), scoped by the farm’s OU. Finally, it reads the registration web service address from the SCPs it finds. This way, it ends up with a list of web services that it can invoke to register with a farm. If the server it is registered with fails, it can simply pick another one.
Finally, here’s a list of other AD-related information that’s relevant for XenDesktop:
- You don’t have to use the AD set-up wizard. If you want to, you can create all the objects in the farm’s OU manually, e.g. through tools such as AD explorer. However, you should be careful to get the keywords in the SCPs right (all GUIDs are constant, but the farm name must be correct), and you need to be careful with who has permissions to change these objects, as mentioned above.
- While the farm OU, computer accounts, and user accounts can all live in different AD domains, all these domains must be in the same AD forest – VDAs and DDCs must be able to resolve each other’s identity (Windows Communication Foundation uses Kerberos to authenticate machines), and of course end users must be able to log on. You must also run the AMC on a machine that is a member of a domain that is trusted by the AD domains containing the computer and user accounts (or run it with a user account that is trusted), otherwise it will not be able to resolve user and computer names and you’ll end up with SIDs displayed instead.
- XenDesktop supports all AD functional levels. However, if you’re running in Windows 2000 mixed mode, restrictions on the scope of security groups mean that the farm OU and the DDC computer accounts must be in the same domain (as pointed out above, it’d be best practice to put the DDC computer accounts into the farm OU anyway).
- The names of the objects in the XenDesktop farm OU are hardcoded and cannot be changed. We have found that some AD environments have very strict policies as to where objects, in particular security groups, can be located and how they are named. If the ‘Controllers’ security group is not suitable in your environment, you can use an arbitrary security group located anywhere in your forest instead. To do this, you must create this group according to your AD policies, populate it with the computer accounts of the DDCs in your farm, and then set the following registry entry on all the VDAs in your farm: the key HLKM\Software\Citrix\ADConfig needs to contain a string value called ServersGroupGuid, and the contents of this value must match the objectGUID attribute of the custom security group (without curly brackets). You can also set this registry entry on the DDC servers, before installing the DDC software: if you do so, the AD set-up wizard will add and remove the DDC computer accounts from the right (i.e. your custom) security group automatically.
- For mutual machine authentication through Kerberos to work, the DDC and VDAs must be able to resolve each other’s DNS names; also, Kerberos is quite picky and you’ll encounter authentication errors if there’s a significant clock skew between the machines (the default settings allow the clocks to drift by up to 5 minutes).
- If you run your virtual desktops as VMs and suspend them for prolonged periods of time, they may get out of sync with computer password changes made by the domain controller. There are a range of Microsoft KB articles on this topic which you may want to check out (be aware of the associated security risks, though). The good news here is that if you use Provisioning Server, it can take over AD computer account management for you, so you don’t have to worry about this.