Deep Dive – How Horizon Utilizes Active Directory

Microsoft Active Directory is the backbone of almost every enterprise network. It is also a very complex system, and large, multi-site organizations can have incredibly complex environments that stretch across multiple Active Directory forests.

I was recently on a support escalation with one of our service provider partners. The escalation revolved around integrating Horizon into a complex Active Directory environment that involved multiple Active Directory forests connected over a trust. While both Horizon and Active Directory were working properly, the design of these particular Active Directory environments caused issues that manifested in Horizon and other applications.

Active Directory

Before talking about how Horizon utilizes Active Directory, I want to do a little level setting. I won’t go into a full overview of Active Directory. This is a very large topic that can, and has, fill books, and Microsoft has some very good documentation on their public documentation site.

One Active Directory design concept that is important for Horizon deployments, especially large deployments where resource forests may be used, is Sites. Active Directory Sites are part of the logical representation of the physical network. They map physical IP space to logical network locations, and they serve multiple purposes in an Active Directory environment. One key role that sites fill is helping clients locate the closest computer that is providing a service. This includes domain controllers.

Windows has a built-in process for locating domain controllers. This process is part of the NetLogon service. During startup, the computer’s NetLogon service detects the site that the computer is located in. The site name is stored in the registry. During logon, NetLogon will use the site name to query for DNS SRV records to locate the domain controller for that site. This process is outlined in this Microsoft blog post. It gets more complicated when you have multiple forests as the site lookup is based on the domain membership of the computer, not the user.

How Horizon Interacts with Active Directory

So what does this have to do with Horizon and how it interacts with Active Directory?

When you set up a new Horizon pod, you’re not required to do any Active Directory setup. The Horizon Connection Server services run in the context of the local system account, and they utilize built-in processes to identify the domain.

The Windows NetLogon service includes processes to retrieve information about the local Active Directory environment, and there are Win32 APIs to allow applications to trigger this process. Horizon utilizes these APIs to discover the local domain and any trusted domains. The Windows DC Locator process will identify the closest domain controller to the site, and any queries against the domain will be targeted to that domain controller using the system’s Active Directory account. (Note: Write Operations, such as creating computer accounts for Instant Clones, will use not use the computer account credentials.)

If the Connection Server is not able to determine the site that it is in, then it will use any domain controller that is returned when querying DNS, and the DC Locator process will continue to query for domain controllers on a regular basis.

When it comes to integrating with Active Directory, Horizon isn’t doing anything special. We’re just building on top of what Microsoft has in Windows Server.

Troubleshooting

If AD sites are not set up properly, you may see performance issues, especially in network scenarios where Horizon cannot reach the domain controller that DNS is pointing them to.

These issues can include Active Directory user and group search results taking a long time to return, issues with user authentication, and issues with computer accounts for provisioned machines. This may also impact user login experience and site-aware services like file shares fronted by DFS Namespaces. These issues are mainly seen in large Active Directory environments with many sites, or in environments with trusts between forests, where sites are not properly set up or maintained.

So how do you troubleshoot Horizon issues with Active Directory? This Microsoft blog post provides a good starting point. You will need to use NetLogon debugging and the nltest command line tool to see what Active Directory site your servers are a member of and what domain controllers are being resolved when the DC Locator process runs.

This can get a little more complicated in cloud deployments, large enterprises or service provider scenarios where resource forests are being used. Site names become very important in these scenarios as the computer will use the local domain site name when searching for domain controllers across trusts. Fixing Active Directory issues in these environments may require site topology changes.

Best Practices

Horizon utilizes native Windows features when integrating with Active Directory. It’s important to have a solid Active Directory architecture and site topology to ensure good performance and user experience. This means having sites defined and subnets assigned to the correct site.

A well-defined site topology becomes very important in environments where a resource forest, connected to the on-premises Active Directory environment with a trust, will be used as the site names must match in both Active Directory environments for the DC Locator process to work properly. Active Directory design needs to be a part of the Horizon design process to avoid issues after deployment.

Horizon View 6.0 Part 4–Active Directory Configuration

When you build a Horizon View environment, the virtual desktops that users connect to run Windows.  The servers that provide the virtual desktop infrastructure services run on Windows.  So, as you can imagine, Active Directory plays a huge role in Horizon View.

When you’re planning a Horizon View deployment, or rearchitecting an existing deployment, the design of your Active Directory environment is a critical element that needs to be considered.  How you organize your virtual desktops, templates, and security groups impacts Group Policy, helpdesk delegation rights, and View Composer.

Some Active Directory objects need to be configured before any Horizon View components are installed.  Some of these objects require special configuration either in Active Directory or inside vCenter.  The Active Directory objects that need to be set up are:

  • An organizational unit structure for Horizon View Desktops
  • Basic Group Policy Objects for the different organizational units
  • An organization unit for Microsoft RDS servers if application remoting is used

Optionally, you may want to set up an organizational unit for any security groups that might be used for entitling access to the Horizon View desktop pools.  This can be useful for organizing those groups and/or delegating access to Help Desk or other staff who don’t need Account Operator or Domain Administrator rights.

Creating An Organizational Unit for Horizon View Desktops

The first think that we need to do to prepare Active Directory for a Horizon View deployment is to create an organizational unit structure for Horizon View desktops.  This OU structure will hold all of the desktops created and used by Horizon View.  A separate OU structure within your Active Directory environment is important because you will want to apply different group policies to your Horizon View desktops than you would your regular desktops.  There are also specific permissions that you will need to delegate to the View Composer service account.

There are a lot of ways that you can set up an Active Directory OU structure for Horizon View.  My preferred organizational method looks like this:

2013-12-28_21-55-14

View Desktops is a top-level OU (ie – one that sites in the root of the domain).  I like to set up this OU for two reasons.  One is that is completely segregates my VDI desktops from my non-VDI desktops and servers.  The other is that it gives me one place to apply group policy that should apply to all VDI desktops such as disabling non-essential services, turning off screen savers, or setting the inactivity timeout to lock the machine.

I create three child OUs under the View Desktops OU to separate persistent desktops, non-persistent desktops, and desktop templates.  This allows me to apply different group policies to the different types of desktops.  For instance, you may want to disable Windows Updates and use Persona Management on non-persistent desktops but allow Windows Updates on the desktop templates.

You don’t need to create all three OUs.  If your environment consists entirely of Persistent desktops, you don’t need an OU for non-persistent desktops.  The opposite is true as well.

Finally, I tend to create department or location OUs underneath the persistent or non-persistent OUs if I have locations that require special Group Policy settings in addition to the default settings.  One example where I used this was in a previous job that HEAVILY used Microsoft Access databases at one site.  Microsoft Access includes a security groups option that uses a centrally stored database file to manage access to databases.  This can be configured with group policy, and since other locations used Access without the security groups configured, applying that policy to all desktops would have broken any Access databases that the other locations used.

These grandchild OUs are completely optional.  If there is no need to set any custom policy for a location or a department, then they don’t need to be created.  However, if a grandchild OU is needed, then an entire pool will need to be created as desktop pools are assigned to OUs.  Adding additional pools can add management overhead to a VDI environment.

Creating an Organizational Unit for RDS Servers

Horizon View 6.0 added PCoIP support for multi-user desktops running on Windows Server with the Remote Desktop Session Host role.  These new abilities also added support for remote application publishing.

RDS servers need to be handled differently than virtual desktops.  They’re managed differently than your virtual desktops, and some features such as Persona Management are not available to RDS servers.

If application remoting or multi-user desktops are going to be deployed, an organizational unit for RDS servers should be created underneath your base servers organizational unit. 

Horizon View Group Policy Objects

Horizon View contains a number of custom group policy objects that can be used for configuring features like Persona Management and optimizing the PCoIP protocol.  The number of Group Policy objects has been increased in Horizon View 6, and the number of templates has increased as well.

Unfortunately, most of the Group Policy templates are distributed as ADM files.  There are a number of drawbacks to ADM files in modern Active Directory environments.  The main one is that you cannot store the Group Policy files in the Central Store.

If you plan on using the Group Policy templates, it’s a good idea to convert them into the ADMX format.  I had previously written about converting the View Group Policy templates into the ADMX format and the reasons for converting here.

Horizon View Service Accounts

Horizon View requires a service account for accessing vCenter to provision new virtual machines.  If View Composer is used, a second service account will be needed to create computer accounts in Active Directory for linked clones.  I will cover setting up those account in a future section.

In the next section, I’ll cover SSL certificates for Horizon View servers.

Horizon View 5.3 Appendix E: Converting The View Group Policy Templates to ADMX

VMware View includes a set of Group Policy templates that can be used to centrally manage settings for View desktops and servers.   These templates are required for fine tuning the behavior of a Horizon View environment and the PCoIP and Blast protocols that are used when connecting to desktops.

Brian Suhr recently wrote a great article on how to deploy the Group Policy templates on Petri. 

There is one main drawback to the Group Policy templates that are included with Horizon View – they’re ADM files.  Prior to Windows Server 2008, Group Policy templates were deployed using ADM files.  If a non-standard ADM file was used as part of a Group Policy Object, that ADM file would be included with the group policy object when it is saved onto the domain Sysvol.  This leads to Sysvol bloat and can have a negative impact on Active Directory Replication.

Microsoft addressed this issue with updates to Group Policy in Windows Server 2008.  Server 2008 allowed Administrators to create a network-based “central store” where the new Group Policy template files are stored.  These templates could then be referenced by any workstation or server that was Vista/Server 2008 or newer when authoring or editing Group Policy without having to install them.

Converting the View ADM Files to ADMX

I haven’t found many tools that convert ADM files to ADMX files.  Microsoft has released a free conversion tool, but it didn’t convert the View ADM files properly, and a number of GPO settings did not work after using this tool.

The only other ADM converter tool that I was able to find was Syspro’s ADM Template Editor.  This $60 tool can edit existing ADM templates or convert them to ADMX files.  A 30-day free trial of the ADM Template Editor is available.

The first thing that you will need to do is download, install, and register ADM Template Editor.  Once you have done this, you can start converting the ADM files.

The steps for converting ADM files to ADMX files using the ADM Template Editor are:

1.   Copy the View ADM files to the server or workstation where ADM Template Editor is installed.  On a default installation of View, the ADM files are located in C:\Program Files\VMware\VMware View\Server\Extras\Group Policy on any Connection Server.

Group Policy Files Location

2.  Open ADM Template Editor.

3. To configure ADM Template editor to save new ADMX files directly into your Group Policy Central Store, go to Setup –> General Setup and enter the path to your Group Policy Central Store into the ADMX directory field. 

ADM Convert Pre-Step

Note: If your Active Directory Administrator has not set up a Group Policy Central Store, please refer them to this article.

4. Go to File –> Add Existing ADM file…

ADM Convert 2

5.  Select the ADM files you want to load and click Open.

ADM Convert 3

5.  Go to File –> Convert ADM to ADMX

ADM Convert 4

6.  Select the ADM file(s) you want to convert and click Convert.

ADM Convert 5

7.  The next screen allows you to change metadata before converting the ADM file.   Make any changes as required and then click OK.

ADM Convert 6

8. Go to File –> Save Files.

ADM Convert 7

9. Click Save As

ADM Convert 8

10. Save the files into a directory where you will be able to find them easily.

ADM Convert 9

11. Open the directory where you saved the ADMX files.  Copy the ADMX files and the language folder to your Group Policy Central Store.

Note: The converted Group Policy templates will not be available at remote Active Directory sites until replication occurs.

12. When you create a new Group Policy object, the converted ADMX templates should be available under Administrative Templates.

ADM Convert 11

Horizon View 5.3 Part 4 – Active Directory and vCenter Configuration

The only desktops that are supported for virtual desktops in Horizon View 5.3 are Windows-based.  This includes the latest versions of the Windows Desktop operating system and Windows Server running Windows Terminal Server or as a desktop.  Because Windows desktops are the core of Horizon View, Active Directory is used to handle authentication into the View environment.

As I mentioned in my last post, an Active Directory environment is a requirement.  Per the documentation, Server 2003 and Server 2008/R2 Active Directory environments are supported.  The documentation doesn’t go into any details as to whether Windows Server 2012 domain controllers are unsupported or if the Server 2012 domain and forest functional levels are unsupported.

Edit 3/26/2014: VMware has updated the release notes for Horizon View 5.3 to clarify support, and the 2012 Domain/Forest functional levels are not supported.  2012 domain controllers are supported. h/t rboyett

Some Active Directory objects need to be configured before any Horizon View components are installed.  Some of these objects require special configuration either in Active Directory or inside vCenter.  The Active Directory objects that need to be set up are:

  • An organizational unit structure for Horizon View Desktops
  • A service account for View Composer
  • A service account that View will use to access vCenter

Optionally, you may want to set up an organizational unit for any security groups that might be used for entitling access to the Horizon View desktop pools.  This can be useful for organizing those groups and/or delegating access to Help Desk or other staff who don’t need Account Operator or Domain Administrator rights.

Creating An Organizational Unit for Horizon View Desktops

The first think that we need to do to prepare Active Directory for a Horizon View deployment is to create an organizational unit structure for Horizon View desktops.  This OU structure will hold all of the desktops created and used by Horizon View.  A separate OU structure within your Active Directory environment is important because you will want to apply different group policies to your Horizon View desktops than you would your regular desktops.  There are also specific permissions that you will need to delegate to the View Composer service account.

There are a lot of ways that you can set up an Active Directory OU structure for Horizon View.  My preferred organizational method looks like this:

2013-12-28_21-55-14

View Desktops is a top-level OU (ie – one that sites in the root of the domain).  I like to set up this OU for two reasons.  One is that is completely segregates my VDI desktops from my non-VDI desktops and servers.  The other is that it gives me one place to apply group policy that should apply to all VDI desktops such as disabling non-essential services, turning off screen savers, or setting the inactivity timeout to lock the machine.

I create three child OUs under the View Desktops OU to separate persistent desktops, non-persistent desktops, and desktop templates.  This allows me to apply different group policies to the different types of desktops.  For instance, you may want to disable Windows Updates and use Persona Management on non-persistent desktops but allow Windows Updates on the desktop templates.

You don’t need to create all three OUs.  If your environment consists entirely of Persistent desktops, you don’t need an OU for non-persistent desktops.  The opposite is true as well.

Finally, I tend to create department or location OUs underneath the persistent or non-persistent OUs if I have locations that require special Group Policy settings in addition to the default settings.  One example where I used this was in a previous job that HEAVILY used Microsoft Access databases at one site.  Microsoft Access includes a security groups option that uses a centrally stored database file to manage access to databases.  This can be configured with group policy, and since other locations used Access without the security groups configured, applying that policy to all desktops would have broken any Access databases that the other locations used.

These grandchild OUs are completely optional.  If there is no need to set any custom policy for a location or a department, then they don’t need to be created.  However, if a grandchild OU is needed, then an entire pool will need to be created as desktop pools are assigned to OUs.  Adding additional pools can add management overhead to a VDI environment.

Creating a View Composer Service Account

There are two service accounts that need to be created in Active Directory to support a Horizon View deployment.  The first is the account that will be used by View Composer.  This account can be created as a standard domain user.  This account should not have domain administrator or account operator rights – it only needs a select group of permissions on the OU (or OUs) where the View Desktops are being stored.

After this account has been created, you need to delegate permissions to it on the OU (or OUs) where your VDI desktops will be placed.  If you use the structure like the one I outlined above, you only need to delegate permissions on the top-level OU and permission inheritance, if turned on, will apply them to any child or grandchild objects beneath it.

Note:  If inheritance is not turned on, you will need to check the Apply to All Child Objects checkbox before applying the permissions.

The permissions that need to be delegated on the OU are:

  • Create Computer Objects
  • Delete Computer Objects
  • Write All Properties
  • Reset Password

Note: Although granting this account Domain Administrator or Account Operator permissions may seem like an easy way to grant it the permissions it needs, it will grant a number of other permissions that are not needed and could pose a security risk if that account is compromised.  Only the required permissions should be granted in a production environment.

Creating a vCenter Server Service Account

The second Active Directory account that needs to be created is a service account that will be used by Horizon View to access vCenter.  Because Horizon View has a number of different configurations, the actual rights required by vCenter will vary.  I will be using View Composer in this series, so I will be setting up the vCenter Service Account with the permissions required to use View Composer.

Note: If you are not using View Composer, or you plan to use View Composer and Local Mode, different permissions will be required in vCenter.  Please see Chapter 8 of the Horizon View 5.2 Installation Guide for more details on the permissions that need to be assigned to the service account.

The user account that is created for accessing vCenter Server should be a standard domain user account.  Unlike the View Composer, it shouldn’t have any rights to administer objects in the domain as the permissions that this account needs will be assigned within vCenter.

To create a new role in the vCenter Web Client, you need to go to Administration –> Roles from the main page.  This will bring up the roles page, and we can create a new role from here by clicking on the green plus sign.

2013-12-29_19-14-37

The permissions that need to be assigned to our new role are:

Edit June 16th, 2014 – The Datastore permissions were missing from the list of permissions needed for the vCenter Service Account.  They have now been added in.

Privilege Group

Privilege

Datastore Allocate Space
Browse Datastore
Low Level File Operations
Folder Create Folder
Delete Folder
Virtual Machine Configuration –> All Items
Inventory –> All Items
Snapshot Management Note 2–> All Items
Interaction:
Power On
Power Off
Reset
Suspend
Provisioning:
Customizing
Deploy Template
Read Customization Spec
Clone Virtual Machine
Allow Disk Access
Resource Assign Virtual Machine to Resource Pool
Migrate Powered-Off Virtual Machine
Global Enable Methods
Disable Methods
System Tag
Act As vCenter Note 1
Network All
Host Configuration:
Advanced Settings Note 1

Note 1: Act as vCenter and Host Advanced Settings are only needed if View Storage Accelerator are used.  If these features are not used, these permissions are not required.

Note 2: The documentation says to grant all permissions to State under virtual machine.  However, in vCenter 5.1 and later, there does not appear to be an item called State.  The state item existed in earlier versions of vCenter and was renamed to Snapshot Management.  For more information, please see this post by Terence Luk.

After the role has been created, we will need to assign permissions for our vCenter Server service account to the vCenter root.  To do this from the roles screen, you will need to go back to the vCenter Web Client Home screen and take the following steps:

  1. Select vCenter
  2. Select vCenter Servers under Inventory Lists
  3. Select the vCenter that you wish to grant permissions on
  4. Click on the Manage Tab
  5. Click Permissions
  6. Click the Green Plus Sign to add a new permission
  7. Select the role for View Composer
  8. Add the Domain User who should be assigned the role
  9. Click OK.

2013-12-29_20-33-59

This wraps up the preparation work for configuring Active Directory and vCenter to support a Horizon View deployment.  Now we can start installing the components for a Horizon View environment beginning with View Composer.

Nervepoint Access Manager

Account lockouts and password resets are two things that IT support personnel frequently deal with.  In my experience, these two tasks make up a large chunk of help desk tickets.

Self-service account management tools do exist, but many of these tools are expensive, and the cost can put them out of reach for small businesses and non-profits.

That is where Nervepoint Access Manager(abbreviated NAM) comes in.  NAM is a Linux-based virtual appliance that provides web-based self-service password reset and account unlock utilities.


Download and Setup
NAM can be downloaded from the Nervepoint website.  The download file is a TAR that contains the VMware vmx and vmdk files, so you will need a program like 7-zip to extract it.  Once downloaded, you will need to upload these files to a datastore in your VMware environment and add the virtual machine to your inventory.

Once the VM is powered on, it will grab a DHCP address.  My test network is small, so I was able to easily find it and log into the administrative web interface to configure my network adapter.  This may be an issue in larger environments or in data centers without DHCP, but there is a community forum post that describes how to configure the network adapter from the console.

Configuring access to Active Directory is fairly easy too.  Opening your web browser and browsing to the Nervepoint appliance will bring up a first-time setup screen.  It will use DNS to detect any Active Directory domains in your environment and connect to them.  You will also need to set up a service account that has permissions to change passwords on any OUs that contain users.

In order to successfully connect to an Active Directory domain, it will need to have LDAP over SSL configured.  For larger environments, this won’t be a problem as they will likely have an Active-Directory integrated PKI environment set up.  For environments that don’t have PKI, it will require at least one Enterprise CA and a Windows Server Enterprise license or a 3rd-party certificate.

Once configured, it is fairly easy for end-users to use.  They will need to log in to configure their answers to the questions that will be used to verify their identity.  Password changes and account unlocks are simple affairs – a user only needs to answer three of the five questions correctly to perform a password reset.


Nervepoint Pros
Despite being a beta, there are several things I like about the Nervepoint appliance.  It is a fairly small VM that uses less than a gigabyte of RAM.  It is suitable for production use in smaller environments, and it is very easy to use.


Nervepoint Cons
Even though I like this appliance a lot and would consider deploying it in my production network, there are a couple of areas for improvement.

For starters, there is very little documentation.  There are no install or administrator guides, and the forums don’t have a lot of information yet.  There is a FAQ section of the website, but it doesn’t have a lot of information in it either.  There is no read-me or license information included with the appliance either.
The VM doesn’t have the VMware tools installed.  I believe that this is something that should have been done by the developers before shipping the appliance.  It’s not a huge deal, but it would help with managing the VM.

I don’t have the ability to customize the security questions that my employees are asked or set the number of questions they must answer correctly.  The ability for administrators to customize these settings may be important in some environments.

And finally, the distribution method for this appliance leaves something to be desired.  The VM is downloaded from the Nervepoint website, and it took multiple attempts to correctly import the virtual machine into my test environment.  A better option might be to package the appliance as an OVF template and list it on the VMware marketplace.


Conclusion
Despite the cons, the Nervepoint Access Manager is a fairly decent little Self-Service Account Management appliance, and I would strongly consider deploying it in my production network in the future.

Edit:  It was brought to my attention by the developers of this product that the license and the default questions can be changed during the initial setup.  I did not have these two items in my notes, and I apologize for the error.