XO Community Edition - Ldap Plugin not working ?

Danp

@kagbasi-ngc Try changing ({name}) to {{name}} in your user filter

kagbasi-ngc

@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

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?

kagbasi-ngc

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

olivierlambert

Okay and regardless XOA or XO from the sources, right?

kagbasi-ngc

@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

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

kagbasi-ngc

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

pdonias

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.

kagbasi-ngc

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

kagbasi-ngc

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

Chico008

Hi
Came back here

still no news for me.
corrected my conf, i put dn= instead of dc=
and changes my filter to : (&(sAMAccountName={{name}})(memberOf=CN="Admins du domaine"))

so i have

URI : ldap://sdc.domain.net:389
check certificat / tls = NO
base : dc=domain,dc=net

credential
dn : xo_user@domain.net
password : xxxxx

use filter : (&(sAMAccountName={{name}})(memberOf=CN="Admins du domaine"))
Id attribute : sAMAccountName

not i got the Could not authenticate user when i'm testing connection.

Code: -32000

Message: could not authenticate user

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

which log can i check to see what's is happening ?

tried testing with just user/password, user@doamin/password
but same error message.

kagbasi-ngc

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

Chico008

@kagbasi-ngc

Using DN i have a totally different error on testing connection
Code: -32000

Message: 80090308: LdapErr: DSID-0C090511, comment: AcceptSecurityContext error, data 52e, v4563 Code: 0x31

{
  "code": 49,
  "message": "80090308: LdapErr: DSID-0C090511, comment: AcceptSecurityContext error, data 52e, v4563\u0000 Code: 0x31",
  "name": "Error",
  "stack": "Error: 80090308: LdapErr: DSID-0C090511, comment: AcceptSecurityContext error, data 52e, v4563\u0000 Code: 0x31\n    at Function.parse (/opt/xen-orchestra/node_modules/ldapts/StatusCodeParser.ts:99:16)\n    at Client._sendBind (/opt/xen-orchestra/node_modules/ldapts/Client.ts:638:30)\n    at Client.bind (/opt/xen-orchestra/node_modules/ldapts/Client.ts:272:5)\n    at AuthLdap._authenticate (/opt/xen-orchestra/packages/xo-server-auth-ldap/src/index.js:270:11)\n    at default.testPlugin (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/plugins.mjs:285:5)\n    at Xo.test (file:///opt/xen-orchestra/packages/xo-server/src/api/plugin.mjs:109:3)\n    at Task.runInside (/opt/xen-orchestra/@vates/task/index.js:172:22)\n    at Task.run (/opt/xen-orchestra/@vates/task/index.js:156:20)\n    at Api.#callApiMethod (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:469:18)"
}

The account i'm testing with have 4 security groups
Service account using to bind only have 1 security group (domain user)
same user is used to bind ldap to other website or software, and works fine.

kagbasi-ngc

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

Davidj 0

@kagbasi-ngc @olivierlambert
I've seen similar problems with other LDAP clients. With those other systems, it was a problem with a fixed buffer size somewhere in the client code. If the list of groups exceeds what will fit in the buffer, we had weird problems. Increasing the buffer size fixed the problem.

olivierlambert

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.

kagbasi-ngc

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

olivierlambert

No, the environment is everything different between XOA and XO from the source:

the VM your run it
the version of it and dependencies
anything else that could makes a diff

We have 0 difference in the XO code itself, so it could be anything around it.

kagbasi-ngc

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