Skip to main content

XenDesktop and Active Directory Integration

You have to start testing the XenDesktop beta and go to the XenDesktop forums to have your questions answered.

This is a snippet copy/paste from the Citrix Blog:

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.

Read the whole article here!

and for beta, Register Now to Download

Comments

Popular posts from this blog

Security: VMware Workstation 6 vulnerability

vulnerable software: VMware Workstation 6.0 for Windows, possible some other VMware products as well type of vulnerability: DoS, potential privilege escalation I found a vulnerability in VMware Workstation 6.0 which allows an unprivileged user in the host OS to crash the system and potentially run arbitrary code with kernel privileges. The issue is in the vmstor-60 driver, which is supposed to mount VMware images within the host OS. When sending the IOCTL code FsSetVoleInformation with subcode FsSetFileInformation with a large buffer and underreporting its size to at max 1024 bytes, it will underrun and potentially execute arbitrary code. Security focus

Virtualization: GlassHouse hopes to cash in with its IPO!

GlassHouse Technologies Inc. on Tuesday registered to raise as much as $100 million in an initial public offering that, despite the company's financial losses, could prove a hit with investors drawn to its focus on "virtualization" technology. The Framingham, Mass., company offers consulting services for companies that use virtualization software to improve the performance of corporate servers and cut costs in their data centers. GlassHouse also provides Internet-based data storage. "Software-as-a-service," or SaaS, companies and vendors of virtualization products have proved popular among investors in recent years as corporate customers seek alternatives to conventional packaged software. GlassHouse, with roots in both sectors, will test the strength of that interest, said Peter Falvey, managing director with Boston investment bank Revolution Partners. "It will be a bit of a bell weather," he says. "It's not as though it's the 15th SaaS m...