By default, XenServer can only be managed with the local root account.
Nevertheless, in production, it will probably be necessary to delegate some operations to specific users.

Then, it will also be possible to limit their rights according to their user account and and the group to which they belong.

To make this possible, Citrix allows you to join your XenServer server to the Active Directory of your intranet.

1. Required configuration
2. Important informations
3. Explanation of available rights (roles)
4. Configuring NTP and DNS settings of the XenServer server
   1. Configuration during the XenServer installation
   2. Configuration with XenCenter after installing XenServer
5. Adding users and groups to the Active Directory
6. Join the XenServer server to the Active Directory
7. Adding AD users and groups to the XenServer server
8. Testing roles associated with AD users and/or groups
   1. User1 : Pool Operator
   2. User2 : VM Operator
   3. User3 : Read Only (promoted to : VM Operator)

1. Required configuration

To implement the Active Directory authentication on your XenServer server, you will need :

• an Active Directory
• a local DNS server (by default, this service is installed at the same time as the Active Directory)
• a NTP server to synchronize the time of your XenServer with your Active Directory. (By default, the Active Directory role installation also installs the NTP service)
• a XenServer server.

In our case, we used 2 servers :

1. a Windows Server 2012 server with the Active Directory role, and the DNS and NTP services that were installed automatically when you installed the Active Directory.
2. a fresh install of XenServer 6.5.0

2. Important informations

Here are some important information for setting up Active Directory authentication on your XenServer server :

• In XenCenter, Active Directory users and groups are called "users". But, in command line (CLI), these are called subjects.
• You must specify the IP address of your Active Directory server as the primary DNS server of your XenServer so that it can resolve the domain name of your Active Directory server.
• Each XenServer server on your network must have an unique name. Otherwise, when you bind your 2nd XenServer server to your Active Directory, the 1st server will no longer be able to connect to your Active Directory server.
  Indeed, as your second XenServer server have the same name, the "computer" object corresponding to your first XenServer server will have been overwritten by the computer object created when you bind your second XenServer server to your Active Directory server.
• If you are using multiple XenServer servers, you should know that your servers can be in different time zones, because the time compared is the UTC time (this time does not vary according to the time zone). However, your XenServer servers must be synchronized with the same NTP server so that they have exactly the same date and time.
• XenServer uses the Kerberos protocol to communicate with your Active Directory. So, your Active Directory server must support this protocol. Otherwise, Active Directory authentication will fail.
• Moving an AD user from one group to another may remove or add rights to a user on your XenServer. (As you will see later in this tutorial)

If your XenServer servers are in a server pool, be aware that it's forbidden to "mix" authentication types.
In other words, all XenServer servers in your server pool must use Active Directory authentication or none will use it.
In summary, you will not be able to enable Active Directory authentication on only a part of the servers of your server pool.

To prevent your XenServer server from becoming inaccessible in the event of a failure of your Active Directory server, XenServer still attempts to authenticate itself :
- locally (to test if the password matches the local root account)
- then, with your Active Directory, if it can be reached.
In other words, if your Active Directory server crashes, you will only be able to connect with the root account of the relevant XenServer server.

Finally, in order for your XenServer server to be able to connect to your Active Directory server, you must allow these ports to output.
Note : this is only an indication, because in our case, no configuration was necessary XenServer to connect to our Active Directory server.

Source : Citrix XenServer 6.5 Service Pack 1 Administrator's Guide (starting from page 3).

3. Explanation of available rights (roles)

By default, XenServer has 6 roles that allow you to apply specific permissions to a user and/or a group.

In XenServer version 6.5.0, you will find these 6 roles :

1. Pool Admin : this role allows you to have the same rights as the local root account of your XenServer server. In other words, you will have the right to do everything (manage server pools, XenServer servers, virtual machines, high availability, ...).
2. Pool Operator : this role allows you to do everything, except to manage users and their rights.
3. VM Power Admin (Virtual Machine Power Administrator) : this role is used to create and manage the XenServer server virtual machines.
4. VM Admin (Virtual Machine Administrator) : this role is similar to the "VM Power Admin" role, except that it does not allow you to migrate (move) virtual machines from one XenServer server to another.
5. VM Operator (Virtual Machine Operator) : this role is similar to the "VM Admin" role, except that it does not allow you to create or delete virtual machines (VMs). Nevertheless, this role allows you to start and stop virtual machines (VM).
6. Read Only : only allows you to view the usage of XenServer server resources and the server statistics.

As shown at the top of the "Select Roles" window, each role in the list inherits the rights available through the roles listed below it.

Finally, be aware that these roles can be assigned to Active Directory users, but also to Active Directory groups.
If a user receives several different roles (one for his user account and another for the Active Directory group to which he belongs), XenServer will assign the role with the most permissions to this user. (As you will see later in this tutorial)