@stormi Yes it does. I just deleted the VTPM and tried starting it, but no success. Still the same issue - can't initialize the display.

I also disabled Secure Boot, and got the same results.

@stormi No worries at all, I understand.

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

@pdonias As requested, I added the log filter to the XO config file, restarted the xo-server service, and then ran the LDAP tester from the UI twice. Afterwards, I then ran journalctl -u xo-server, and this is all I see in the logs:

ON XOA:

Dec 16 17:15:59 xoa xo-server[418777]: 2024-12-16T22:15:59.962Z xo:api WARN user | plugin.test(...) [165ms] =!> Error: could not authenticate user
Dec 16 17:17:46 xoa xo-server[418777]: 2024-12-16T22:17:46.904Z xo:api WARN user | plugin.test(...) [13ms] =!> Error: could not authenticate user

ON XOCE:

Dec 16 17:22:34 XO1 xo-server[85750]: 2024-12-16T22:22:34.618Z xo:api WARN user | plugin.test(...) [62ms] =!> Error: could not authenticate user
Dec 16 17:23:04 XO1 xo-server[85750]: 2024-12-16T22:23:04.792Z xo:api WARN user | plugin.test(...) [11ms] =!> Error: could not authenticate user

I am still able to login, if I reduce the security groups I'm member of to 2 or less. 3 or more, results in failure.

@pdonias Will do as requested and report back. I have a meeting to get to now, but should be able to do this afterwards.

@olivierlambert As promised, I checked my user account at work and it is a member of 5 security groups, and the primary group is not Domain Users.

@olivierlambert When I get to work tomorrow, I'll check my AD account in my lab to see how many groups I'm a member of. If you'll recall, I didn't have any issue at all getting the plugin to work on the first try within the air-gapped test lab.

@olivierlambert Yes sir.

Would you like me to create a video of it happening? I'm home all day today, so I can run any test you need me to. Just let me know.

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

@Danp Good catch!

I fixed it and I was now getting the previous error I was getting:

plugin.test
{
  "id": "auth-ldap",
  "data": {
    "username": "yykagbasi",
    "password": "* obfuscated *"
  }
}
{
  "message": "could not authenticate user",
  "name": "Error",
  "stack": "Error: could not authenticate user
    at /opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server-auth-ldap/src/index.js:246:15
    at default.testPlugin (file:///opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server/src/xo-mixins/plugins.mjs:285:5)
    at Xo.test (file:///opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server/src/api/plugin.mjs:109:3)
    at Task.runInside (/opt/xo/xo-builds/xen-orchestra-202412100608/@vates/task/index.js:172:22)
    at Task.run (/opt/xo/xo-builds/xen-orchestra-202412100608/@vates/task/index.js:156:20)
    at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server/src/xo-mixins/api.mjs:469:18)"
}

So that got me thinking that perhaps there was a special character in my password that was causing the query to fail. It was interest to me that the LDAP bind was successful, but the query was returning no results, even though the response packet (as seen in Wireshark) contain results that I thought were valid.

So I performed several tests, with various variations of my username and password combinations. I even created a new user and test - the results were mixed. Sometimes succeeding and sometimes failing. However, I noticed that all the successful tests were with the new test account I'd created, not my personal account. So I compared the two, and realized that my account was part of 9 Security Groups whereas the test account was a member of only 2 Security Groups. So to confirm, I removed myself from all but 2 groups and tested, and it was successful. To confirm, I added myself to a 3rd group and tested - FAILURE.

So, at this juncture, it seems as though when a user is a member of more than 2 groups in AD, the LDAP query is failing (or at least the plugin test if failing - haven't attempted to login to XO to confirm).

Has anybody seen this behavior in their environments? By the way, I noticed this behavior in both XOA and XOCE.

UPDATE:

• I confirmed that as long as I kept my AD Group Membership to less than 3, I was able to login using my domain credentials. The moment I added a 3rd group, login failed.

• Noticed also that if my primary group is anything other than Domain Users, login fails (even if my group count is under 3).

@olivierlambert Thanks for extending the trial, much appreciated. I was able to activate the auth-ldap plugin (v0.10.10) with the same settings I used in my XOCE instance and it failed the test, even though the Wireshark capture seems to suggest the bind was successful.

ERROR MESSAGE IN XOA:

plugin.test
{
  "id": "auth-ldap",
  "data": {
    "username": "yykagbasi",
    "password": "* obfuscated *"
  }
}
{
  "message": "Illegal unescaped character: ( in value: ({name}",
  "name": "Error",
  "stack": "Error: Illegal unescaped character: ( in value: ({name}
    at Function._unescapeHexValues (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/FilterParser.ts:334:17)
    at Function._parseExpressionFilterFromString (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/FilterParser.ts:247:29)
    at Function._parseString (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/FilterParser.ts:198:31)
    at Function._parseString (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/FilterParser.ts:154:44)
    at Function.parseString (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/FilterParser.ts:31:38)
    at Client.search (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/Client.ts:584:31)
    at AuthLdap._authenticate (/opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server-auth-ldap/src/index.js:277:55)
    at default.testPlugin (file:///opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server/src/xo-mixins/plugins.mjs:285:5)
    at Xo.test (file:///opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server/src/api/plugin.mjs:109:3)
    at Task.runInside (/opt/xo/xo-builds/xen-orchestra-202412100608/@vates/task/index.js:172:22)
    at Task.run (/opt/xo/xo-builds/xen-orchestra-202412100608/@vates/task/index.js:156:20)
    at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server/src/xo-mixins/api.mjs:469:18)"
}

WIRESHARK CAPTURE:

@stormi Hi there, as requested, here are the two logs:

• daemon.log
• xensource.log

I started the VM at timestamp Dec 13 13:54:59 and stopped it at Dec 13 13:55:59.

Now, is deleting the symbolic link created above all that is necessary to reverse the debug mode?

@stormi Glad you're not spooked....

I'll enable the debug mode as you'd instructed and grab the logs for you shortly.

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

@stormi Yikes! If you're spooked by this error, then what does this mean for me?

By the way, this very VM imported and started up without any issues on a physical XCP-ng host. This issue seems to be happening in a nested virtualization setting - where XCP-ng is the nested hypervisor (a guest of VMware Workstation Pro).

@stormi My apologies. Normally I relish the opportunity to dive deep into logs, however, in this case I am also the treasurer of my church and I have year-end accounting tasks to accomplish, so haven't had much time to dedicate to this.

Additionally, since I don't really know what I'm looking for in the logs, I figured it's be best to share it on hear for the community to take a look...lol.

@olivierlambert You're most welcome. XCP-ng + Xen Orchestra is a solid solution and I would very much like to see it get adopted within my organization, so I'll do anything (legal of course) to work through these problems and share the solutions, so the entire community can benefit.

@olivierlambert I tried to but got a message that I've already consumed my trial. I did I did a trial a couple of years back when I was first introduced to XCP-ng, can't recall exactly.

Would it be possible to grant me another trial? If so, my account is tied to kagbasi [AT] wgsdac.org

@olivierlambert So after resolving the control domain space issues, I was able to successfully deploy XOA to the same host and wanted to test out the LDAP settings on XOA, but noticed that only two plugins come loaded with the install:

How do I install the LDAP plugin?

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

@stormi @olivierlambert

As requested, please find the outputs of the logs:

• Output of xl dmesg - https://gist.github.com/kismetgerald/403edf28d5fd358722d2bc36b52f38f1
• Output of /var/log/daemon.log - https://gist.github.com/kismetgerald/8965863047eee26b815dcfcfe4faabae
• Output of /var/log/xensource.log - https://gist.github.com/kismetgerald/4ed62e999d9920d697f06c8e42de9873

For time reference, I started the VM at approximately Dec 12 05:08 - don't recall the precise second. If I can provide other logs, please let me know.