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
Labels:

Comments

Post a Comment

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
Post a Comment
Read more

OS Virtualization comparison: Parallels' Virtuozzo vs the rest

Virtuozzo's main differentiators versus hypervisors center on overhead, virtualization flexibility, administration and cost. Virtuozzo requires significantly less overhead than hypervisor solutions, generally in the range of 1% to 5% compared with 7% to 25% for most hypervisors, leaving more of the system available to run user workloads. Customers can also virtualize a wider range of applications using Virtuozzo, including transactional databases, which often suffer from performance problems when used with hypervisors. On the administration side, customers need to manage, maintain and secure just a single OS instance, while the hypervisor model requires customers to manage many OS instances. Of course, the hypervisor vendors have worked hard to automate much of this process, but it still requires more effort to manage and maintain multiple operating systems than a single instance. Finally, OS virtualization with Virtuozzo has a lower list price than the leading hypervisor for comme...
Post a Comment
Read more