XO Community Edition - Ldap Plugin not working ?
-
@olivierlambert Which logs please? I'm still learning so not familiar with where all the logs are, outside of what I see within XO - and those errors are very vague.
-
@olivierlambert I have tried deploying XOA using a static IP and the result is the same. It fails after 80% completion, with that exclamation sign. As before, I see the VM on the host but it does not have the IP address I set and it does not start (hangs at 83%).
Any other way I can get XOA?
-
@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?
-
You need to start a trial
-
@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
-
New trial generated
-
@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:
-
@kagbasi-ngc Try changing
({name})
to{{name}}
in your user filter -
@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).
-
-
So do you confirm, regardless XOA or XO from the sources, as soon as you get a group with more than 3 ppl you have an issue?
-
@olivierlambert No, it's the other way around. Once the subject user is a
memberof
3 or more groups, the problem occurs. -
Okay and regardless XOA or XO from the sources, right?
-
@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.
-
I don't see it's needed. It's maybe something weird between AD and the LDAP plugin (or a misconfig somewhere?)
IDK what kind of debug could help, pinging @pdonias
-
@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.
-
Hi @kagbasi-ngc,
To try and figure out what's happening, you can add this to your xo-server config:
[logs] filter = 'xo:auth-ldap
Then run the plugin test again and see if xo-server's logs give more information.
-
@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
. -
@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.