@kagbasi-ngc I figured out what the problem was, so wanted to post it for the benefit of the community.

The root cause for me ended up being a firewall issue on the Windows Server where I was running the NFS server role. While I hadn't made any changes to the firewall, the profile of the network interface connected to the management network had changed from Domain to Public/Private, thus, Windows Defender Firewall applied the most restrictive settings since it saw that the NIC wasn't connected to the Domain profile (even though it physically was).

This post on Serverfault (https://serverfault.com/a/647201/189248) clued me in and I looked at the Network Location Awareness service (NLA). It was set automatic and was running, so I restarted it and this reverted the profile of the NIC back to Domain and caused Windows Defender Firewall to apply the previously configured rules.

It is important to note that this situation won't be common, as most of you won't be running your NAS on a dual-homed domain controller that is also running the DHCP server role. Hope this helps someone.

@Prilly Looks like @lawrencesystems has a good explainer video on YouTube at https://youtu.be/weVoKm8kDb4?si=QH93rOKaXLglrIbS

Check it out when you get a chance, thanks.

@nathanael-h Yeah, I've already done that several times and no luck.

What I'm gonna try now is see if I can boot it with the Windows installation disk, go into recovery and access the WinPE command line, and see if I can run xenbootfix.exe to clean out the guest tools/drivers.

If that doesn't work, I'll just blow away the VM and start over. I just hate doing this, cos it doesn't give us the chance to figure out why this happened.

@olivierlambert Cool, I'll run the other two when I get back. I'll kick them off simultaneously.

@olivierlambert No sir, I have not. I'll try that and report back shortly.

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

@stormi Sorry for the delayed reply. I did as you requested, and below are the resulting log files. I started the VM at timestamp Dec 17 14:43:34 and stopped it about 2 minutes later.

• daemon.log
• xensource.log

If I can be of assistance, don't hesitate to ask please. Thank you.

@olivierlambert No, it's the other way around. Once the subject user is a memberof 3 or more groups, the problem occurs.

@manilx Yeah, not doing it in production, just in a test environment. Plus I only did it because I actually found a write-up by the Vates team on how to get it done, which confirmed to me that while they don't recommend it for production, they understand that it has some merit in a testing environment and want to see it working.

That said, I definitely hear your admonition and would never do it in a production setting.

@olivierlambert Certainly strange, then, that the same settings and same plugin works in XOA but not in XOCE. We could argue perhaps some configuration variances within the Domain Controllers, but given that I'm the same person that configured both environments - I'm highly confident that I stood up the DCs in the same way. Only things that would obviously be different would be the Domain Name and OU Structure.

I'll confirm the Forest and Domain functional levels later this evening and perhaps run an XOA trial and see if it works. I'll report back.

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