Existing AD Users Cannot Login to XOCE but New Users Can

kagbasi-wgsdac

I considered the possibility of account lockouts but I've carefully checked each time the test failed and neither the bind account nor the test account were locked.

olivierlambert

So next step is to try with XOA. It's weird because we don't have other reports, and usually with LDAP, the context is almost everything (configuration, accounts, groups…)

kagbasi-wgsdac

@olivierlambert

As instructed, I deployed XOA, grabbed a trial license, and updated it to the latest version then tried again; same results. Getting the following error for my admin account (same one I use to log into every other workstation on the network

Code: -32000
Message: could not authenticate user
{
  "message": "could not authenticate user",
  "name": "Error",
  "stack": "Error: could not authenticate user\n    at /usr/local/lib/node_modules/xo-server-auth-ldap/src/index.js:254:15\n    at default.testPlugin (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/plugins.mjs:280:5)\n    at Xo.test (file:///usr/local/lib/node_modules/xo-server/src/api/plugin.mjs:109:3)\n    at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:417:20)"
}

If I then use one of the test accounts I had created AFTER I started noticing the failed attempts (i.e., after 05/15/2023), it works.

Plugin test
The test appears to be working.

Prior to testing, I logged into the Domain Controller and verified that the service account I'm using to bind to AD was not locked. I'm willing to send whatever screenshots or outputs you need if it helps to get to the bottom of this.

olivierlambert

@julien-f can you remind me the name of the CLI tool to debug wrong LDAP config?

julien-f

@olivierlambert xo-server-auth-ldap.

kagbasi-wgsdac

@olivierlambert

I had already posted the output of the test-cli.js utility at the beginning of this thread, however, if you want I can do it again just to re-confirm things. Just let me know, thanks.

olivierlambert

Okay so to me it's either a weird configuration thing or a library problem in your context.

I don't know what else to do form a community point of view. You might ask on Passport library if the problem rings a bell.

@julien-f is there anything else you think we can do as far it is community support?

kagbasi-wgsdac

@olivierlambert I am very grateful for the assistance thus far. I definitely understand that your time is money, and I'm willing to approach my Church Leadership with a request to purchase the Enterprise License. However, do you offer any discounts off the annual subscription for Non-Profits Organizations? I'd be happy to take this discussion offline if you prefer (kagbasi at wgsdac.org).

Secondly, is this the correct GitHub project for the passport library you mentioned: https://github.com/vesse/passport-ldapauth/issues ? If so, I'll try posting a question there as well, as you've suggested.

olivierlambert

Checking with @julien-f

julien-f

@kagbasi-wgsdac From what I understand, there is no issue in the XO plugin itself (because it's working in many cases), it appears to be related to your LDAP/AD configuration, and unfortunately we cannot help regarding this as each LDAP/AD can be configured differently

The library we are using to connect to LDAP is https://github.com/ldapts/ldapts but I don't think that will help because it's more likely something on your server's side.

kagbasi-wgsdac

@julien-f Hmm, that's a bit disappointing that there isn't much you guys can do to help. No worries, I'll keep testing. My AD environment works fine, since the accounts in question are not locked and are being used daily. The only place they're failing is in XOCE or XOA.

It's gotta be something with how the library is handling characters in either the username or the password. I'll keep testing until I can find a repeatable pattern.

Thanks to both you and @olivierlambert for the help thus far.