Xen Orchestra Active Directory Group Import Debug

love2scoot

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

olivierlambert

Questions for @pdonias or @lsouai-vates

dinhngtu

@love2scoot I used a very similar config to yours which worked. Have you tried doing a manual query with Ldp.exe?

URI: ldaps://<DC FQDN>
Copy ADCS root CA to /usr/local/share/ca-certificates/root.crt
Certificate Authorities: fill
- /usr/local/share/ca-certificates/root.crt
Check certificate: enabled
StartTLS: disabled
Base: OU=...
Credentials: fill
dn: <service account UPN>
password: <password>
User filter: (userPrincipalName={{name}})
ID attribute: dn

Group information: fill
Base: OU=...
Filter (domain local groups only): (&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=4))
ID attribute: dn
Display name attribute: cn
Members mapping:
- Group: member
- User: dn

love2scoot

@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!

olivierlambert

I do think we have a tool for that, ping @julien-f because I don't remember myself

pdonias

@love2scoot You can add this to your xo-server config file:

[logs]
filter = 'xo-server-auth-ldap'

Then xo-server's logs will only contain logs coming from the LDAP plugin, including more debug logs during a group sync. Don't forget to remove it once you're done to get your logs back to normal.

love2scoot

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

olivierlambert

Still, I remember we had a dedicated CLI tool to test it