@dinhngtu Thanks for the response here.

SOLVED

As per your suggestion, I was able to bind to my AD server using ldp.exe and was able to verify my filter through search. This further validated the query I was trying to run against the AD server.

Looking through your settings, the only real different in our configurations was the Display name attribute field. I changed this field from sAMAccountname to cn and the query succeeded when clicking the Synchronize LDAP groups button. So, although sAMAccountname works as a valid field for the user query (and appears to be populated for all group objects on my AD Domain), this does not appear to work when querying for group objects with XO (at least against my AD Domain).

Suggestion: So while this is solved (at least in my case), there currently doesn't appear to be an easy way to debug ldap query results which are originating from the XO server. Having at least a simple log entry for LDAP queries (or at least a way to enable this through a verbose flag) would go a long way to understanding what's going on behind the scenes with XO + LDAP.

Thanks for the help!

This was reported a few hours ago over on the XenOrchestraInstallerUpdater github page: https://github.com/ronivay/XenOrchestraInstallerUpdater/issues/288

Just to be sure, I attempted a fresh install on top of Ubuntu v24.04LTS and found the same issues as upgrade attempts on my existing XO VMs.

bluerockny created this issue in ronivay/XenOrchestraInstallerUpdater

closed Update failure #288

Xen Orchestra User ACLs and UI Privileges

I have been trying to track down how Xen Orchestra ACLs are expressed within the XO UI. While some general guidance exists, I have not found a source of comprehensive documentation on the subject. To resolve this, I built a Xen Orchestra ACL Mapping spreadsheet which walks through the granular application of each ACL privilege and to which UI elements it grants the user access.

The challenge with the XO UI and ACLs

When applying an ACL privilege for a specific user (or group), it is not clear to which UI components the user is granted access. This stems from the fact that:

• Some UI elements are not present for a user without a specific permission
• Some UI elements are present for a user without a specific permission, but are non functional (like buttons that can be pressed, but result in a "Not enough permissions" popover)
• Some UI elements only become functional when multiple ACL entries of different types are added for a specific user (or group), leading to cases where dependencies need to be understood.
• Some UI elements will never appear to non-SuperAdmin users regardless of the ACL granted.

XO Resource Hierarchy

Xen Orchestra resources can be local (connected to an XO host directly) or shared across a Pool (and therefore not directly connected with any specific Host). For the purposes of this spreadsheet, it should be assumed that only shared resources are considered (unless otherwise noted). This would mean that items like ISO shares (for example) are accessed via network sharing and do not use local Host resources. These resources are organized into a hierarchy and expressed as:

• Pool - The collection of resources
  • Host - The hypervisor is a pool member
  • SR - A network connected storage repository
  • VM - A virtual machine built on top of network storage
  • Network - A specific network interface which belongs to the pool

How to understand this spreadsheet

Quick summary on how the spreadsheet was designed

Columns

XO ACLs can be granted to (5) different object types, each with (3) different levels of access. These ACLs are represented by columns within the spreadsheet, ordered from least permissive to most permissive:

• Network Object ACL (Viewer - Operator - Admin)
• SR Object ACL (Viewer - Operator - Admin)
• VM Object ACL (Viewer - Operator - Admin)
• Host Object ACL (Viewer - Operator - Admin)
• Pool Object ACL (Viewer - Operator - Admin)

(2) additional columns are included which detail which UI components are present by default for:

• A SuperAdmin user
• A User without any ACLs granted

Rows

The rows of the spreadsheet delineate which UI components are available to the user. This has been ordered to match the hierarchy of the Xen Orchestra GUI. Rows are grouped by their relationship to major UI sections. For example, all rows which allow the user to make changes to Storage Objects use the same cell background color.

Cells

The spreadsheet cells express how a given ACL permission allows for access to a specific UI component. There are (5) possible values for these cells:

• Yes - The UI component is present and the user can manipulate with the given ACL permission.
• No - The UI component is present but the user cannot manipulate with the given ACL permission.
• Dependency - The UI component requires additional ACL permissions be granted before the user is capable of manipulating. Cells of this type also include an embedded comment field to detail which additional ACL permission(s) are required.
• UI Hidden - The UI element is completely hidden from the interface given the specific ACL permissions.
• Unknown - In some cases I didn't have spare resources which I could use for testing (For example: I didn't want to test out Force Restart of one of my Hosts). In these cases the specific ACL was not tested.

Housekeeping

• This spreadsheet refers to the XO5 UI. I have not attempted access of the XO6 UI at the time of creation.
• These ACL grants can be applied to either a user or group, but the user in question is not specified as a SuperAdmin.
• Although I have tried to double check my results, it's possible that I have recorded some of these ACL results incorrectly. If that's the case, drop a note in this thread and I will attempt to test and update where applicable.

@lsouai-vates I'm happy to contribute where I can

Xen Orchestra User ACLs and UI Privileges

I have been trying to track down how Xen Orchestra ACLs are expressed within the XO UI. While some general guidance exists, I have not found a source of comprehensive documentation on the subject. To resolve this, I built a Xen Orchestra ACL Mapping spreadsheet which walks through the granular application of each ACL privilege and to which UI elements it grants the user access.

The challenge with the XO UI and ACLs

When applying an ACL privilege for a specific user (or group), it is not clear to which UI components the user is granted access. This stems from the fact that:

• Some UI elements are not present for a user without a specific permission
• Some UI elements are present for a user without a specific permission, but are non functional (like buttons that can be pressed, but result in a "Not enough permissions" popover)
• Some UI elements only become functional when multiple ACL entries of different types are added for a specific user (or group), leading to cases where dependencies need to be understood.
• Some UI elements will never appear to non-SuperAdmin users regardless of the ACL granted.

XO Resource Hierarchy

Xen Orchestra resources can be local (connected to an XO host directly) or shared across a Pool (and therefore not directly connected with any specific Host). For the purposes of this spreadsheet, it should be assumed that only shared resources are considered (unless otherwise noted). This would mean that items like ISO shares (for example) are accessed via network sharing and do not use local Host resources. These resources are organized into a hierarchy and expressed as:

• Pool - The collection of resources
  • Host - The hypervisor is a pool member
  • SR - A network connected storage repository
  • VM - A virtual machine built on top of network storage
  • Network - A specific network interface which belongs to the pool

How to understand this spreadsheet

Quick summary on how the spreadsheet was designed

Columns

XO ACLs can be granted to (5) different object types, each with (3) different levels of access. These ACLs are represented by columns within the spreadsheet, ordered from least permissive to most permissive:

• Network Object ACL (Viewer - Operator - Admin)
• SR Object ACL (Viewer - Operator - Admin)
• VM Object ACL (Viewer - Operator - Admin)
• Host Object ACL (Viewer - Operator - Admin)
• Pool Object ACL (Viewer - Operator - Admin)

(2) additional columns are included which detail which UI components are present by default for:

• A SuperAdmin user
• A User without any ACLs granted

Rows

The rows of the spreadsheet delineate which UI components are available to the user. This has been ordered to match the hierarchy of the Xen Orchestra GUI. Rows are grouped by their relationship to major UI sections. For example, all rows which allow the user to make changes to Storage Objects use the same cell background color.

Cells

The spreadsheet cells express how a given ACL permission allows for access to a specific UI component. There are (5) possible values for these cells:

• Yes - The UI component is present and the user can manipulate with the given ACL permission.
• No - The UI component is present but the user cannot manipulate with the given ACL permission.
• Dependency - The UI component requires additional ACL permissions be granted before the user is capable of manipulating. Cells of this type also include an embedded comment field to detail which additional ACL permission(s) are required.
• UI Hidden - The UI element is completely hidden from the interface given the specific ACL permissions.
• Unknown - In some cases I didn't have spare resources which I could use for testing (For example: I didn't want to test out Force Restart of one of my Hosts). In these cases the specific ACL was not tested.

Housekeeping

• This spreadsheet refers to the XO5 UI. I have not attempted access of the XO6 UI at the time of creation.
• These ACL grants can be applied to either a user or group, but the user in question is not specified as a SuperAdmin.
• Although I have tried to double check my results, it's possible that I have recorded some of these ACL results incorrectly. If that's the case, drop a note in this thread and I will attempt to test and update where applicable.

@pdonias Very nice! This is exactly what I was looking for.

@dinhngtu Thanks for the response here.

SOLVED

As per your suggestion, I was able to bind to my AD server using ldp.exe and was able to verify my filter through search. This further validated the query I was trying to run against the AD server.

Looking through your settings, the only real different in our configurations was the Display name attribute field. I changed this field from sAMAccountname to cn and the query succeeded when clicking the Synchronize LDAP groups button. So, although sAMAccountname works as a valid field for the user query (and appears to be populated for all group objects on my AD Domain), this does not appear to work when querying for group objects with XO (at least against my AD Domain).

Suggestion: So while this is solved (at least in my case), there currently doesn't appear to be an easy way to debug ldap query results which are originating from the XO server. Having at least a simple log entry for LDAP queries (or at least a way to enable this through a verbose flag) would go a long way to understanding what's going on behind the scenes with XO + LDAP.

Thanks for the help!

Summary:

Despite having success with AD user logins via the auth-ldap plugin, I cannot seem to figure out the AD group import process.

Background:

• XO Community Edition commit ca227 built on Ub24.04LTS
• auth-ldap v0.10.10
• MS Server 2019 Standard: AD server at DNS server.addomain.publicdomain.com
• LDAPS enabled on AD server using LE/ACME public certificate

auth-ldap Configuration (leaving out the group config here):

• URI: ldaps://server.addomain.publicdomain.com
• Certificate Authorities / Fill information (optional): checked
  • Check certificate: unchecked
  • StartTLS: unchecked
  • Base: DC=addomain,DC=publicdomain,DC=com
• Credentials / Fill information (optional): checked
  • dn: ldapuser@publicdomain.com
  • password: obfuscated
• User filter:
  (&(sAMAccountName={{name}})(|(memberOf=CN=dev-xo_access,OU=Groups,DC=addomain,DC=publicdomain,DC=com)(MemberOf=cn=IT,ou=Groups,dc=addomain,dc=publicdomain,dc=com)(MemberOf=cn=Domain Admins,cn=Users,dc=addomain,dc=publicdomain,dc=com)))
• ID attribute: dn

Here's what works:

• Successful XO login using AD user credentials of an authorized user
  • I can login to XO using an AD account as long as the AD user is a member of one of the AD groups specified in the User filter field.
  • Once this succeeds, the user is populated in XO GUI "Settings / Users".
  • This simulates a successful AD user XO access via AD group membership
  • This is the desired behavior
• Unsuccessful XO login of unauthorized AD user
  • If I attempt to login to XO with an AD account which is not a member of one of the AD groups specified in the User filter field, the login fails and the user's account is not present in XO GUI "Settings / Users".
  • This simulates an unsuccessful AD user XO access via AD group membership
  • This is the desired behavior
• Unsuccessful XO login of previously authorized user, whose access was removed
  • If I remove a user (which had previously successfully logged into XO with AD credentials and is therefore present in "Settings / Users") from all the AD groups in the User filter field, the user can no longer log into XO
  • This simulates XO access removal via AD Group membership removal
  • This is the desired behavior

This validates the following:

• Connections to AD using :636 and the ldaps protocol are working as expected
• Plugin authentication using the Credentials work
• Authentication using the SAMAccountName field works as expected
• AD Group membership can be correctly used as part of the XO authentication process
• XO access can be removed using AD group membership, even if the user previously logged into XO successfully
• Using the Base, DC=addomain,DC=publicdomain,DC=com is successful for both users and group LDAP queries

The above gives me access to LDAP (AD) users via XO, which then allows me to add the XO user objects to XO ACLs- this is a great first step. However, like may organizations, our access is managed via group membership. So, ideally, we get AD Groups synced into XO and then use these groups to add to an ACL, allowing for seamless XO access (both to the XO GUI and to ACLs) provided by AD group membership.

Here's what doesn't work:

Synchronize groups (auth-ldap group config area):

• Fill information (optional): checked
• Base: DC=addomain,DC=publicdomain,DC=com
• Filter: (ObjectClass=group)
• ID attribute: dn
• Display name attribute: sAMAccountName
• Members mapping / Group attribute: member
• Members mapping / User attribute: dn

Process:

• Navigate to Settings / Groups
• Click Synchronize LDAP groups button
• Confirm warning "Are you sure you want to synchronize LDAP groups with XO? This may delete XO groups and their ACLs." with OK
• Nothing - page refreshes, but no error, no groups listed, no UI feedback or prompts

Debugging processes attempted:

• Verified that AD Groups are ObjectClass group, have a dn, and configured with membership using the "member" attribute
  • powershell: get-adgroup IT -properties * | fl
  • ObjectClass is group
  • dn correctly populated
  • "member" object array contains members of the group specified by dn
• Look for errors in the XO GUI (Settings / Logs): No results
• (ssh to XO) Look for errors in the xo-server log: journalctl -u xo-server: No results
• (ssh to XO) Look for errors in the raw json: /srv/xo/xo-server/dist/logs-cli.mjs: No results
• Specify a slightly reduced scope for the Base (OU=Groups,DC=addomain,DC=publicdomain,DC=com) in the synchronize groups plugin settings: No results
• Check Windows Server logs / Security: Can see Audit Success from the XO server IP, so it appears that the server is authenticating
• Toggle the auth-ldap plugin: No results
• Restart the XO server: No results

What would be nice:

• Some insight into how the ldap queries are logged on the xo-server side
• A way of tracking how query result are used as input to XO group / user object creation
• Ideas on other debugging methods available

This was reported a few hours ago over on the XenOrchestraInstallerUpdater github page: https://github.com/ronivay/XenOrchestraInstallerUpdater/issues/288

Just to be sure, I attempted a fresh install on top of Ubuntu v24.04LTS and found the same issues as upgrade attempts on my existing XO VMs.

bluerockny created this issue in ronivay/XenOrchestraInstallerUpdater

closed Update failure #288