This page describes user management in the XO 5 interface. XO 6 currently lists users (with their groups and tokens); creating and editing them still happens here. See what lives where.
Xen Orchestra involves three distinct notions of "user account". Make sure you are looking at the right one:
XOA system accounts: the Linux accounts (xoa, root) of the appliance itself, used for SSH and console access. See First login.
XO application users: the accounts inside the Xen Orchestra web application. This is what this page is about.
XO 6 / REST API roles: XO 6 introduces a new RBAC model (ACL v2) with roles and fine-grained privileges. See the ACL v2 page.
There are 2 types of XO users:
admins, with all rights on all connected resources
users, with no rights by default
note
Local user accounts should be avoided in production environments. LDAP authentication is strongly recommended for centralized credential management.
Xen Orchestra supports various types of user authentication, internal or even external thanks to the usage of the Passport library.
tip
Any account created by an external authentication process (LDAP, SSO...) will be a user without any permission.
Also, you don't have to create an external user by yourself: it will be created automatically in Xen Orchestra after its first connection.
Xen Orchestra supports Time-based One-Time Password (TOTP) to provide an additional layer of security for your user account. When enabled, you will be required to provide a temporary code from an authentication app in addition to your standard credentials during login.
To disable this feature, return to your profile settings and toggle the OTP authentication switch to Off. You will be asked to provide a final OTP code to confirm the deactivation.
XO currently supports connections to LDAP directories, like Open LDAP or Active Directory, through the auth-ldap plugin.
Access the plugin:
Navigate to the Settings → Plugins screen.
Locate the auth-ldap plugin by scrolling or using the search bar.
Configure LDAP settings:
Click the + button for the LDAP plugin.
A list of settings appears:
zoomed detailThe auth-ldap plugin settings: URI, certificates, base, credentials, user filter and ID attribute
Fill in the required fields based on your LDAP server details: the URI of the server, the Base where users are looked for, the User filter and the ID attribute (which must be unique and stable, e.g. dn). Optional fields cover failover URIs, certificate authorities and certificate checking, StartTLS and the credentials used to search the directory.
Save and activate:
Click Save configuration.
To check if the plugin is activated, activate the toggle switch next to the auth-ldap plugin name.
The switch should now appear green.
LDAP Filters allow you to properly match your user. Finding the right filter is no easy task, and it entirely depends on your LDAP configuration.
Still, here is a list of common filters:
'(uid={{name}})' is usually the default filter for Open LDAP.
'(cn={{name}})', '(sAMAccountName={{name}})', '(sAMAccountName={{name}}@<domain>)' or even '(userPrincipalName={{name}})' are widely used for Active Directory.
Please check with your AD Admin to find the right one.
Once configured, users can authenticate using their LDAP credentials. Upon a successful initial login, the user's account will appear in the XO user list.
The LDAP plugin allows for the synchronization of user groups.
Access group synchronization settings
To configure the synchronization:
Go to the Synchronize groups section.
Check the box called Fill information (optional).
A list of text fields appear.
Fill out the fields according to the picture below:
zoomed detailThe Synchronize groups section of the auth-ldap plugin, with base, filter, ID and display name attributes
Basic group settings:
Base and Filter: Similar to the user configuration. The plugin needs an entry point in the directory and a filter to find the groups.
ID attribute: The attribute used by the plugin to uniquely identify each group. The ID attribute must be unique across groups and not change over time.
On each synchronization, the plugin will compare LDAP groups with XO groups, then try to match them based on this attribute and create or update XO groups if necessary.
Display name attribute: Set the attribute used as the group's name in Xen Orchestra.
Members mapping:
This part of the configuration is used to determine which LDAP users belong to which LDAP groups.
For example, here's an LDAP directory:
User:
objectClass: Person
cn: Bruce Wayne
uid: 347
...
Group:
objectClass: Group
cn: heroes
displayName: Heroes
gid: 456
member: 347
member: 348
...
The plugin needs to know that Bruce Wayne is part of the heroes group. To do so, you need to set 2 entries in the configuration:
Group attribute: the name of the group attribute that is used to list users within a group. In this example, it would be member.
User attribute: the name of the user attribute that is used to reference users in groups. In this example, it would be uid since 347, 348, etc. are user uids.
Save the configuration and you're good to go. From now on, every time an LDAP user logs into XO, the plugin will automatically create or update that user's groups and add them to those groups.
Importing all groups manually
If you need to import all the groups at once, you can do so from Settings → Groups → Synchronize LDAP Groups.
This can be useful if you want to assign ACLs on groups without having to wait for a member of the group to log in.
tip
Importing the groups won't import their members. Users will still be imported one by one when they log in for the first time.
tip
To find the LDAP users, enter this filter in the users table: authProviders:ldap?.
If users can authenticate but group memberships are not reflected:
Verify Your Group Filter
Check if your LDAP group filter is too restrictive. By default, the filter should match all relevant groups.
Example of a broad filter:
(objectclass=posixGroup)
If you are using a more specific filter, ensure that it correctly matches your intended groups. For instance, if you only sync a specific group, it may look like this:
(&(objectclass=posixGroup)(cn=group1))
This filter will only synchronize group1. To sync all groups, remove the (cn=group1) condition.
Verify that the Group Attribute and User Attribute in the plugin configuration match the corresponding attributes in your LDAP directory.
Ensure that the ID Attribute for both users and groups is unique and correctly specified.
Check XO logs for any synchronization errors and adjust configurations accordingly.
Fill in the mandatory fields: the Client identifier (key) and Client secret from your identity provider. You also need to tell the plugin where to find your provider's endpoints, either way:
Auto-discovery URL: the OIDC discovery URL provided by your identity provider (the simplest option), or
the Advanced section, by filling the Authorization URL, Issuer, Token URL and User info URL manually.
To support passkeys in XOA, the Keycloak server must expose its OIDC endpoints over HTTPS.
The TLS certificates used by Keycloak must satisfy the following conditions:
Common Name (CN): The CN of the certificate has to match the DNS name that clients will use to reach Keycloak.
SubjectAltName (SAN): The certificate must contain a SAN entry with the same DNS name.
Certificate chain: The certificate must be issued by a trusted CA. The auth-oidc plugin does not accept self-signed certificates that lack a proper chain of trust.
info
The TLS certificate must match the domain that will be used as the Relying Party ID (RP ID). The RP ID cannot be an IP address; it must be the DNS name that appears in the certificate's CN or SAN.
Here is a certificate that meets these requirements:
Version: 3 (0x02)
Serial number: 7096756171258138755 (0x627cbe2335671083)
Algorithm ID: SHA256withRSA
Issuer
CN = poc
Subject
CN = keycloak.poc.local
Fingerprints
...
extKeyUsage :
serverAuth
subjectAltName :
dns: keycloak.poc.local
With this configuration, Keycloak can participate in passkey authentication flows that XOA expects, and the auth-oidc plugin will correctly validate the TLS connection.
Initiate the OIDC authentication request from the XOA client to Keycloak.
zoomed detailXOA redirecting the OIDC authentication request to Keycloak
The user supplies their username and password at the Keycloak login screen.
zoomed detailThe Keycloak login screen asking for username and password
After credential validation, Keycloak presents a second-factor challenge (User Verification or User Presence) that requires the user to press their Yubikey to complete the authentication.
zoomed detailThe Keycloak second-factor challenge waiting for the security key
When registering your Xen Orchestra instance to your identity provider, you must configure its callback URL to https://<xo.company.net>/signin/saml/callback!
In the "Settings" then "Plugins" view, expand the SAML plugin configuration. Then provide the needed fields:
zoomed detailThe auth-saml plugin configuration: certificate, entry point, issuer and username field
Certificate: copy/paste the identity provider's certificate.
Entry point: entry point of the identity provider.
Issuer: issuer string to supply to the identity provider.
Username field: field to use as the XO username. Try http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress if you are using Microsoft Entra ID (Azure Active Directory).
Optional settings let you disable the requested authentication context (known to help with Active Directory), force re-authentication, and require signed assertions or signed responses.
Save the configuration and then activate the plugin (button on top).
warning
Since XO 5.111.1, you need to configure signature for Document and Assertion in your SAML Identity Provider: either the response or the assertion must be signed.
Keycloak: In Client Settings, Signature and Encryption, check "Sign Documents" and "Sign Assertion".
Azure: In SAML Signing Certificate options, select Sign SAML response and assertion.
Google Workspace: In the Service Provider details, check the Signed response box.
Give your app a name and optionally a description.
To see how the fields should be filled out, refer to the screenshots below.
note
Right now even when the authorization is successful, you will be redirected to the https://xo.company.net/signin page. However, just browse directly into the bare URL https://xo.company.net, and you'll now be logged in and can use the XO dashboard.
tip
If you get a certificate error, try to add a newline at the bottom of the Certificate field in Xen Orchestra.
The first login will create the user inside XO, as a non-privileged user. An administrator then has to promote the user to the appropriate group. (XO: Settings/Users).
zoomed detailThe Google Workspace custom SAML app details, side by side with the matching XO plugin fields
Also make sure to adjust the SAML attribute mapping in the Google Workspace configuration. (Primary email -> email)
zoomed detailThe Google Workspace SAML attribute mapping, with Primary email mapped to email
The auth-github plugin allows any GitHub user to authenticate to Xen Orchestra.
The first time a user signs in, XO will create a new XO user with the same identifier (i.e. GitHub name), with user permissions. An existing admin will need to apply the appropriate permissions for your environment.
First you need to configure a new app in your GitHub account. Go to your GitHub settings > "Developer Settings" > "OAuth Apps" > "New OAuth App".
Name your GitHub application under "Application Name".
Enter your Xen Orchestra URL (or IP) under "Homepage URL"
zoomed detailThe GitHub OAuth App registration form, with the XO homepage and callback URLs filled in
When you get your Client ID and your Client secret, you can configure them in the GitHub plugin inside the "Settings/Plugins" view of Xen Orchestra. They are the only two fields to fill in.
zoomed detailThe auth-github plugin configuration, with the Client ID and Client secret fields
Be sure to activate the plugin after you save the configuration (button on top). When it's done, you'll see a link in the login view, this is where you'll go to authenticate:
zoomed detailThe XO login page with the GitHub sign in link below the credentials form
zoomed detailCreating a new project in the Google developer console
Configure an OAuth consent screen if requested then create OAuth 2.0 credentials:
zoomed detailThe Create credentials menu, with OAuth client ID selected zoomed detailThe OAuth client creation form, with the authorized redirect URI pointing to the XO callback
Get your client ID and client secret:
zoomed detailThe modal displaying the generated OAuth client ID and client secret
In Settings, then Plugins, expand the Google plugin details and configure it with the information from the Google Console:
zoomed detailThe auth-google plugin configuration: callback URL, client ID and client secret
Callback URL: must be exactly the same as specified on the Google developer console.
Client ID and Client secret: the credentials generated above.
warning
The optional scope setting selects which profile information is used to build the XO username (Google+ name or simple email address). Changing this value after users started logging in will break existing users.
Be sure to activate the plugin after you save the configuration (button on top).
You can now connect with your Google account in the login page.
The self-service feature allows users to create new VMs. This is different from delegating existing resources (VMs) to them, and it leads to a lot of possibilities.
To allow people to create VMs as they want, we need to give them a part of your XCP-ng/XenServer resources (disk space, CPUs, RAM). You can call this "general quotas" if you like. But you first need to decide which resources will be used.
In this example below, we'll create a set called "sandbox" with:
"devs" is the group that can use this set (all users in the group)
"Lab Pool" is the pool where they can play
"Debian 8 Cloud Ready" is the only template they can use
"SSD NFS" is the only SR where they can create VMs
"Pool-wide network with eth0" is the only available network for them
zoomed detailThe resource set creation form: name, subjects, pools, templates, SRs, networks and limits, with the eligible hosts below
As you can see, only compatible hosts are shown and can be used for this resource set (hosts in another pool aren't shown). This way, you can be sure to have resources free for tasks other than self-service.
tip
Don't forget to add an ISO SR to allow your users to install VMs with CD if necessary
Replicated VMs and snapshots created by a backup job don't use quotas.
tip
A snapshot of a Self Service VM will use as much resources as a VM would. You can disable this by setting ignoreVmSnapshotResources to true in the selfService section of xo-server's config.
When you click on create, you can see the resource set and remove or edit it:
zoomed detailThe saved resource set recap, with its quota gauges for CPUs, RAM and disk usage
Now, your authorized users can create VMs with their SSH keys, grow template disks if needed, etc. Everything is inside a "sandbox" (the resource set) you defined earlier!
XO Audit Log is a plugin that records all important actions performed by users and provides the administrators an overview of each action. This gives them an idea of the users behavior regarding their infrastructure in order to track suspicious activities.
structure: records are chained using the hash chain structure which means that each record is linked to its parent in a cryptographically secure way. This structure prevents the alteration of old records.
hash upload: the hash chain structure has limits, it does not protect from the rewrite of recent/all records. To reduce this risk, the Audit log plugin regularly uploads the last record hash to our database after checking the integrity of the whole record chain. This functionality keeps the records safe by notifying users in case of alteration of the records.
