@olivierlambert Awesome! Can't wait.

@olivierlambert Aah, you got me there. Thanks for all the support thus far, really appreciate it.

@olivierlambert Thanks for the response, that's good to know that you guys have this on the roadmap. I didn't raise a support ticket because I'm not a paying customer yet, so don't want to come off as exploiting resources that could be dedicated to your paying customers.

That said, I will send this in via a support ticket. Thanks again.

Good-day Folks,

Happy Friday; I trust we're all in good health!

BLUF: I believe the current XOA upgrade option for those of us whose environments fall under the Physical air gap only section of the Airgap support and deployment documentation, leaves us with a new appliance and no way to preserve the historical logs and/or artifacts of the existing AND approved XOA instance.

In my environment, all hardware changes (i.e., new additions, modifications, removal, etc.) MUST go through a formal approval process - which almost always includes going through a Change Control Board (CCB) - yes, this includes any updates/upgrades to virtual machines. This process can often times take several days to weeks to complete. With the only upgrade option available, at this time, the imported VM is essentially a "new" virtual machine, thus, triggers the aforementioned CCB approval process. Additionally, I observed yesterday - after receiving an updated XOA image from support and importing it using the deploy script you provide - that although I was able to very easily export the XO-Config from the existing appliance and import it into the new appliance and essentially get back to the same configuration state (exception being some plugins had to be re-enabled), I was missing historical artifacts - most notably was the logs of the XOA appliance.

Given the above explanation, is there any chance that Vates will consider providing a patching mechanism similar to how you handle XCP--ng (i.e., with an offline repo)? This way, we can download the relevant files, setup a repo on the air-gapped network, then patch the appliance - thus preserving it's historical artifacts AND identity, and most importantly, not triggering an approval process.

@anthonyper said in Imported VM Starts but Does Not Initialize the Display:

yum update --enablerepo=xcp-ng-aperard1 edk2

YES - you fixed it! Thank you!!!
I tried the package and it worked - the VM started and was able to initialize the display and finish booting up. Glad you found the issue and I'm even more glad that it was my report that prompted you to look into this. This is a true testament to the power of this community.

@olivierlambert I have just submitted a Github issue for this - https://github.com/vatesfr/xen-orchestra/issues/8351

Thanks again for indulging me.

kismetgerald-ngc created this issue in vatesfr/xen-orchestra

open LDAP/Active Directory Authentication Fails if User is Member of More than 6 Groups #8351

@olivierlambert Awesome, glad I could convince ya . I will submit a Github issue shortly, thanks again.

@olivierlambert Thanks.

XOA Test results:

• On Stable v5.102.1 - issue persists. Auth failure occurs with AD group membership at 7.

• On Latest v5.103.1 - issue persists. Auth failure occurs with AD group membership at 7.

I can make a screen recording of my testing, if that helps lend more credibility? Just let me know, thanks.

@olivierlambert I have an XOA instance on the Stable channel (v5.102.1) which I'd pulled down earlier to troubleshoot another issue with you, however, my trial has ended so all the plugins have been unloaded.

I can test if you'll reactivate my trial (kagbasi at wgsdac.org). Let me know.

@olivierlambert So, as luck would have it, I left work early to get ahead of a snow storm. When I got home, I decided to spin up a Debian 12 VM and build XO from sources myself while the kids were doing homework (by following the instructions here - https://docs.xen-orchestra.com/installation#from-the-sources).

In a nutshell, I was able to replicate the problem. My test user account could only authenticate successfully AFTER I reduced its group membership in Active Directory to two. Out of curiosity, I incremented the group membership by one and then tested, and kept doing that until I arrived at a max of six. The minute I added the seventh group, authentication failed. This is happening on both this new instance of XOCE and the existing instance I have in production on my church's small network.

Both instances are up-to-date (git commit 8f877).

Here's the console output of the VM while running the tests:

2025-02-11T23:42:17.461Z xo:api WARN admin@admin.net | plugin.test(...) [34ms] =!> Error: could not authenticate user
2025-02-11T23:44:14.072Z xo:api WARN admin@admin.net | plugin.test(...) [14ms] =!> Error: could not authenticate user
2025-02-11T23:45:07.777Z xo:xo-server-auth-ldap INFO successfully bound as CN=yAgbasi\, Kismet,OU=Privileged Users,OU=Users,OU=WGSDAC,DC=wgsdac,DC=net => ykagbasi authenticated
2025-02-11T23:45:07.783Z xo:xo-server-auth-ldap INFO syncing groups...
2025-02-11T23:45:07.898Z xo:xo-server-auth-ldap INFO done syncing groups

PLUGIN CLI (SUCCESSFUL)
So I tried the plugin's test-cli and this is the output. I'm curious as to why the objectGUID value is mangled.

root@XO2:~/xen-orchestra/packages/xo-server-auth-ldap/dist# node test-cli.js
? URI ldap://x.x.x.x:389
? fill optional Certificate Authorities? No
? fill optional Check certificate? No
? fill optional Use StartTLS? No
? Base OU=WGSDAC,DC=wgsdac,DC=net
? fill optional Credentials? Yes
? Credentials > dn CN=xxXenOrchestra Service Account,OU=Service Accounts,OU=Users,OU=WGSDAC,DC=wgsdac,DC=net
? Credentials > password SUPERSECRETPASSWORD
? fill optional User filter? Yes
? User filter (&(sAMAccountName={{name}})(memberOf=CN=IT_XenOrchestra_Admins,OU=Groups,OU=WGSDAC,DC=wgsdac,DC=net))
? ID attribute sAMAccountName
? fill optional Synchronize groups? Yes
? Synchronize groups > Base OU=Groups,OU=WGSDAC,DC=wgsdac,DC=net
? Synchronize groups > Filter (objectClass=group)
? Synchronize groups > ID attribute dn
? Synchronize groups > Display name attribute cn
? Synchronize groups > Members mapping > Group attribute member
? Synchronize groups > Members mapping > User attribute dn
configuration saved in ./ldap.cache.conf
? Username ykagbasi
? Password [hidden]
2025-02-12T00:06:49.730Z xo:xo-server-auth-ldap DEBUG attempting to bind with as CN=xxXenOrchestra Service Account,OU=Service Accounts,OU=Users,OU=WGSDAC,DC=wgsdac,DC=net...
2025-02-12T00:06:49.741Z xo:xo-server-auth-ldap DEBUG successfully bound as CN=xxXenOrchestra Service Account,OU=Service Accounts,OU=Users,OU=WGSDAC,DC=wgsdac,DC=net
2025-02-12T00:06:49.741Z xo:xo-server-auth-ldap DEBUG searching for entries...
2025-02-12T00:06:49.746Z xo:xo-server-auth-ldap DEBUG 1 entries found
2025-02-12T00:06:49.746Z xo:xo-server-auth-ldap DEBUG attempting to bind as CN=yAgbasi\, Kismet,OU=Privileged Users,OU=Users,OU=WGSDAC,DC=wgsdac,DC=net
2025-02-12T00:06:49.748Z xo:xo-server-auth-ldap INFO successfully bound as CN=yAgbasi\, Kismet,OU=Privileged Users,OU=Users,OU=WGSDAC,DC=wgsdac,DC=net => ykagbasi authenticated
2025-02-12T00:06:49.749Z xo:xo-server-auth-ldap DEBUG {
  "dn": "CN=yAgbasi\\, Kismet,OU=Privileged Users,OU=Users,OU=WGSDAC,DC=wgsdac,DC=net",
  "objectClass": [
    "top",
    "person",
    "organizationalPerson",
    "user"
  ],
  "cn": "yAgbasi, Kismet",
  "sn": "yAgbasi",
  "c": "US",
  "l": "Severn",
  "st": "MD",
  "description": "For Testing Xen Orchestra LDAP Auth failures",
  "postalCode": "21144",
  "givenName": "Kismet",
  "distinguishedName": "CN=yAgbasi\\, Kismet,OU=Privileged Users,OU=Users,OU=WGSDAC,DC=wgsdac,DC=net",
  "instanceType": "4",
  "whenCreated": "20230716100123.0Z",
  "whenChanged": "20250211234414.0Z",
  "displayName": "Kismet yAgbasi",
  "uSNCreated": "1222253",
  "memberOf": "CN=IT_XenOrchestra_Admins,OU=Groups,OU=WGSDAC,DC=wgsdac,DC=net",
  "uSNChanged": "6046408",
  "co": "United States",
  "department": "Communications Department",
  "company": "Washington-Ghanaian SDA Church",
  "name": "yAgbasi, Kismet",
  "objectGUID": "mX�_���F�.�i�lq�",
  "userAccountControl": "512",
  "badPwdCount": "0",
  "codePage": "0",
  "countryCode": "840",
  "badPasswordTime": "0",
  "lastLogoff": "0",
  "lastLogon": "0",
  "pwdLastSet": "133837909104346381",
  "primaryGroupID": "513",
  "objectSid": "\u0001\u0005\u0000\u0000\u0000\u0000\u0000\u0005\u0015\u0000\u0000\u0000�A�\u0015�d�G�:��q\u0006\u0000\u0000",
  "adminCount": "1",
  "accountExpires": "9223372036854775807",
  "logonCount": "0",
  "sAMAccountName": "ykagbasi",
  "sAMAccountType": "805306368",
  "userPrincipalName": "ykagbasi@wgsdac.org",
  "lockoutTime": "0",
  "objectCategory": "CN=Person,CN=Schema,CN=Configuration,DC=wgsdac,DC=net",
  "dSCorePropagationData": [
    "20230716110107.0Z",
    "16010101000000.0Z"
  ],
  "lastLogonTimestamp": "133837910540472258"
}
root@XO2:~/xen-orchestra/packages/xo-server-auth-ldap/dist#

@ph7 I still appreciate your contribution, nonetheless. I have reached out to support for assistance with the latest build, so we'll see how that goes.

@olivierlambert Will do, thanks.

@olivierlambert That's fair, I'll bring it up there. I'll also find some time and build XOCE myself (using the instructions you provide in your documentation) and see if the problem follows.

MY ENVIRONMENT:

• XCP-ng: 3 nodes running v8.3
• XOA: v5.98.1 Build: 20241024 (air-gapped build)

Last Friday (February 7th) I enabled the perf-alert plugin and turned on all the options and accepted the defaults. This morning when I came into the lab, I had received about 11,000 email alerts. They were all pointing to the DVD drives SR on each host having hit the 80% threshold (see screenshot below).

So, I looked at the plugin configuration page and noticed that there was an option to exclude a SR. However, I noticed that none of the DVD drives were available to be selected for exclusion. This seems odd to me, so I wanted to bring it up for discussion to see if anybody had any input on how to handle this issue.

Getting this many alerts in such a short period of time, without a way to turn them off (without turning off the alerting altogether) doesn't seem like an acceptable solution.

@olivierlambert thank you sir. So what's the path forward?

What do you need from the community to help you dedicate some developer resources to solving this problem, as it's clearly not impacting just one person.

@olivierlambert said in XO Community Edition - Ldap Plugin not working ?:

If there's no issue in XOA but XO from the source, it's very likely an environment problem, because we don't have any specific LDAP code difference between source and XOA.

What exactly do you mean by this?

I'm not a developer, so in almost all cases I defer to you - @olivierlambert - and the other knowledgeable members of the Vates team. However, in this case, I'm struggling to accept your logic. If by environment you're referring to the Active Directory configuration, then - at least - in my environment, that is the common denominator (i.e., the variable that hasn't changed). The fact that XOA works against the same AD domain but XOCE doesn't (unless a user's security groups are limited to no more than 2), hints to me that something is different in how the LDAP plugin is being implemented in XOA. Now, I didn't compile it myself but relied on @ronivay's install script, so it's very possible that perhaps there's something in how he compiles that's causing the issue - but I feel it important to emphasize that the AD environment hasn't changed - at least in my environment.

I have other systems that are authenticating against the same AD backend, that I'm not having any issues with. If you guys can dedicate some time to troubleshooting this issue, I'm available to assist in any way possible (even if it means burning the midnight oil - just let me know).

@Chico008 So in my XOCE instance, I have been able to consistently reproduce the issue if the user account that is logging in (not the service account binding to AD) is part of more than 2 security groups. So maybe test that and see.

If you watch an LDAP capture in Wireshark, you'll see what I'm talking about. The bind is always successful, but somehow when the LDAP query gets passed it always fails when there are more than 2 security groups (at least in my instance).

Note that this issue doesn't present itself in XOA, only XOCE.

@Chico008 The only thing I can see different between your configuration and mine is that for the credentials, I'm actually using the Distinguished Name exactly as it is in AD, not the UPN. Take a look at my working configuration again - https://xcp-ng.org/forum/post/86545

I'm curious - how many security groups is the failing user a member of in AD?

@ecoutinho Thanks for chiming in. I managed to figure out the math, but thanks nonetheless.

@Danp Aaah, thanks for pointing me to these resources. After reading, I thought it best to simply increase the quotas in my resource set definition to accommodate.

I felt having to modify the config file was too clunky. This seems like something that should be exposed in the UI when defining the resource set.