Defining users, groups, roles and permissions allows you to control who has access to your XenServer hosts and pools and what actions they can perform.
When you first install XenServer, a user account is added to XenServer automatically. This account is the local super user (LSU), or root, which is authenticated locally by the XenServer computer.
The LSU, or root, is a special user account intended for system administration and has all rights or permissions. In XenServer, the LSU is the default account at installation. The LSU is only authenticated by XenServer and does not require any external authentication service. If an external authentication service should fail, the LSU can still log in and manage the system. The LSU can always access the XenServer physical server through SSH.
You can create additional users by adding the Active Directory accounts through either XenCenter's User's tab or the xe CLI. If your environment does not use Active Directory, you are limited to the LSU account.
When you create new users, XenServer does not assign newly created user accounts RBAC roles automatically. As a result, these accounts do not have any access to the XenServer pool until you assign them a role.
These permissions are granted through roles, as discussed in the section called “Authenticating Users With Active Directory (AD)”.
If you want to have multiple user accounts on a server or a pool, you must use Active Directory user accounts for authentication. This lets XenServer users log in to a pool's XenServers using their Windows domain credentials.
The only way you can configure varying levels of access for specific users is by enabling Active Directory authentication, adding user accounts, and assign roles to those accounts.
Active Directory users can use the xe CLI (passing appropriate
-pw arguments) and also connect to the host using XenCenter. Authentication is done on a per-resource pool basis.
Access is controlled by the use of subjects. A subject in XenServer maps to an entity on your directory server (either a user or a group). When external authentication is enabled, the credentials used to create a session are first checked against the local root credentials (in case your directory server is unavailable) and then against the subject list. To permit access, you must create a subject entry for the person or group you wish to grant access to. This can be done using XenCenter or the xe CLI.
If you are familiar with XenCenter, note that the XenServer CLI uses slightly different terminology to refer to Active Directory and user account features:
|XenCenter Term||XenServer CLI Term|
|Add users||Add subjects|
Even though XenServer is Linux-based, XenServer lets you use Active Directory accounts for XenServer user accounts. To do so, it passes Active Directory credentials to the Active Directory domain controller.
When added to XenServer, Active Directory users and groups become XenServer subjects, generally referred to as simply users in XenCenter. When a subject is registered with XenServer, users/groups are authenticated with Active Directory on login and do not need to qualify their user name with a domain name.
By default, if you did not qualify the user name (for example, enter either mydomain\myuser or firstname.lastname@example.org), XenCenter always attempts to log users in to Active Directory authentication servers using the domain to which it is currently joined. The exception to this is the LSU account, which XenCenter always authenticates locally (that is, on the XenServer) first.
The external authentication process works as follows:
The credentials supplied when connecting to a server are passed to the Active Directory domain controller for authentication.
The domain controller checks the credentials. If they are invalid, the authentication fails immediately.
If the credentials are valid, the Active Directory controller is queried to get the subject identifier and group membership associated with the credentials.
If the subject identifier matches the one stored in the XenServer, the authentication is completed successfully.
When you join a domain, you enable Active Directory authentication for the pool. However, when a pool is joined to a domain, only users in that domain (or a domain with which it has trust relationships) can connect to the pool.
Manually updating the DNS configuration of a DHCP-configured network PIF is unsupported and might cause Active Directory integration, and consequently user authentication, to fail or stop working.
XenServer supports use of Active Directory servers using Windows 2003 or later.
Active Directory authentication for a XenServer host requires that the same DNS servers are used for both the Active Directory server (configured to allow for interoperability) and the XenServer host. In some configurations, the active directory server may provide the DNS itself. This can be achieved either using DHCP to provide the IP address and a list of DNS servers to the XenServer host, or by setting values in the PIF objects or using the installer if a manual static configuration is used.
Citrix recommends enabling DHCP to broadcast host names. In particular, the host names
linux should not be assigned to hosts.
XenServer hostnames should be unique throughout the XenServer deployment.
Note the following:
XenServer labels its AD entry on the AD database using its hostname. Therefore, if two XenServer hosts have the same hostname and are joined to the same AD domain, the second XenServer will overwrite the AD entry of the first XenServer, regardless of if they are in the same or in different pools, causing the AD authentication on the first XenServer to stop working.
It is possible to use the same hostname in two XenServer hosts, as long as they join different AD domains.
The XenServer hosts can be in different time-zones, as it is the UTC time that is compared. To ensure synchronization is correct, you may choose to use the same NTP servers for your XenServer pool and the Active Directory server.
Mixed-authentication pools are not supported (that is, you cannot have a pool where some servers in the pool are configured to use Active Directory and some are not).
The XenServer Active Directory integration uses the Kerberos protocol to communicate with the Active Directory servers. Consequently, XenServer does not support communicating with Active Directory servers that do not utilize Kerberos.
For external authentication using Active Directory to be successful, it is important that the clocks on your XenServer hosts are synchronized with those on your Active Directory server. When XenServer joins the Active Directory domain, this will be checked and authentication will fail if there is too much skew between the servers.
Host names must consist solely of no more than 63 alphanumeric characters, and must not be purely numeric.
Once you have Active Directory authentication enabled, if you subsequently add a server to that pool, you are prompted to configure Active Directory on the server joining the pool. When you are prompted for credentials on the joining server, enter Active Directory credentials with sufficient privileges to add servers to that domain.
Active Directory integration. Make sure that the following firewall ports are open for outbound traffic in order for XenServer to access the domain controllers.
|137||UDP||NetBIOS Name Service|
|139||TCP||NetBIOS Session (SMB)|
|445||TCP||SMB over TCP|
|464||UDP/TCP||Machine password changes|
|3268||TCP||Global Catalog Search|
To view the firewall rules on a Linux computer using iptables, run the following command:
iptables - nL.
XenServer uses Likewise (Likewise uses Kerberos) to authenticate the AD user in the AD server, and to encrypt communications with the AD server.
How does XenServer manage the machine account password for AD integration? Similarly to Windows client machines, Likewise automatically updates the machine account password, renewing it once every 30 days, or as specified in the machine account password renewal policy in the AD server. For more information, refer to http://support.microsoft.com/kb/154501.
Procedure 2.1. Enabling external authentication on a pool
External authentication using Active Directory can be configured using either XenCenter or the CLI using the command below.
xe pool-enable-external-auth auth-type=AD \ service-name=
The user specified needs to have
Add/remove computer objects or workstations privileges, which is the default for domain administrators.
If you are not using DHCP on the network used by Active Directory and your XenServer hosts, use you can use these two approaches to setup your DNS:
Set up your domain DNS suffix search order for resolving non-FQDNs:
xe pif-param-set uuid=
pif-uuid_in_the_dns_subnetwork\ “other-config:domain=suffix1.com suffix2.com suffix3.com”
Configure the DNS server to use on your XenServer hosts:
xe pif-reconfigure-ip mode=static dns=
Manually set the management interface to use a PIF that is on the same network as your DNS server:
xe host-management-reconfigure pif-uuid=
External authentication is a per-host property. However, Citrix advises that you enable and disable this on a per-pool basis – in this case XenServer will deal with any failures that occur when enabling authentication on a particular host and perform any roll-back of changes that may be required, ensuring that a consistent configuration is used across the pool. Use the host-param-list command to inspect properties of a host and to determine the status of external authentication by checking the values of the relevant fields.
To allow a user access to your XenServer host, you must add a subject for that user or a group that they are in. (Transitive group memberships are also checked in the normal way, for example: adding a subject for group
A, where group
A contains group
user 1 is a member of group
B would permit access to
user 1.) If you wish to manage user permissions in Active Directory, you could create a single group that you then add and remove users to/from; alternatively, you can add and remove individual users from XenServer, or a combination of users and groups as your would be appropriate for your authentication requirements. The subject list can be managed from XenCenter or using the CLI as described below.
When authenticating a user, the credentials are first checked against the local root account, allowing you to recover a system whose AD server has failed. If the credentials (i.e. username then password) do not match/authenticate, then an authentication request is made to the AD server – if this is successful the user's information will be retrieved and validated against the local subject list, otherwise access will be denied. Validation against the subject list will succeed if the user or a group in the transitive group membership of the user is in the subject list.
When using Active Directory groups to grant access for Pool Administrator users who will require host ssh access, the number of users in the Active Directory group must not exceed 500.
Procedure 2.3. Allowing a user access to XenServer using the CLI
To add an AD subject to XenServer:
xe subject-add subject-name=
The entity name should be the name of the user or group to which you want to grant access. You may optionally include the domain of the entity (for example, '
xendt\user1' as opposed to '
user1') although the behavior will be the same unless disambiguation is required.
Procedure 2.4. Using the CLI to Revoke User Access
Find the user's subject identifier. This is the user or the group containing the user (removing a group would remove access to all users in that group, providing they are not also specified in the subject list). To do this use the
subject list command:
This returns a list of all users.
You may wish to apply a filter to the list, for example to find the subject identifier for a user named
user1 in the
testad domain, you could use the following command:
xe subject-list other-config:subject-name='
Remove the user using the subject-remove command, passing in the subject identifier you learned in the previous step:
xe subject-remove subject-uuid=
You may wish to terminate any current session this user has already authenticated. See Terminating all authenticated sessions using xe and Terminating individual user sessions using xe for more information about terminating sessions. If you do not terminate sessions the users whose permissions have been revoked may be able to continue to access the system until they log out.
Once a user is authenticated, they will have access to the server until they end their session, or another user terminates their session. Removing a user from the subject list, or removing them from a group that is in the subject list, will not automatically revoke any already-authenticated sessions that the user has; this means that they may be able to continue to access the pool using XenCenter or other API sessions that they have already created. In order to terminate these sessions forcefully, XenCenter and the CLI provide facilities to terminate individual sessions, or all currently active sessions. See the XenCenter help for more information on procedures using XenCenter, or below for procedures using the CLI.
Procedure 2.6. Terminating all authenticated sessions using xe
Execute the following CLI command:
Procedure 2.7. Terminating individual user sessions using xe
Determine the subject identifier whose session you wish to log out. Use either the session-subject-identifier-list or subject-list xe commands to find this (the first shows users who have sessions, the second shows all users but can be filtered, for example, using a command like xe subject-list other-config:subject-name=xendt\\user1 – depending on your shell you may need a double-backslash as shown).
Use the session-subject-logout command, passing the subject identifier you have determined in the previous step as a parameter, for example:
xe session-subject-identifier-logout subject-identifier=
When you leave the domain (that is, disable Active Directory authentication and disconnect a pool or server from its domain), any users who authenticated to the pool or server with Active Directory credentials are disconnected.
Use XenCenter to leave an AD domain. See the XenCenter help for more information. Alternately run the pool-disable-external-auth command, specifying the pool uuid if required.
Leaving the domain will not cause the host objects to be removed from the AD database. See this knowledge base article for more information about this and how to remove the disabled host entries.