@olivierlambert Oh nice, hope it's not too cold over there. It's 9AM over here in Maryland and a bit nippy but not too cold.
Nope, no host or pool logs available (both are empty). Then again, I cleared all the alerts from the dashboard earlier this morning, so not sure if that's what wiped all the logs. I'm not too worried, as this is a testing environment so I'm using this host to do a lot of learning.
@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.
@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.
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.
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 LOL, of course I did.
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 This issue still persists. I've updated my XOCE instance; I am currently at the following versions:
Should I file a bug report? (I found a similar issue: https://github.com/vatesfr/xen-orchestra/issues/3846)
@olivierlambert Aah, good to know. That explains why I couldn't find any instances of winbind or SSSD...lol.
Anyway, I'm willing to help in any capacity to help further this along. So please let me know if you need me to pull any logs or screenshots, and I'll gladly do it.
@olivierlambert My apologies. I've updated and retested, the issue persists.
MY ENVIRONMENT:
xo-server 5.114.1 / Xen Orchestra, commit 01ba1 / xo-web 5.117.1
I think I may have found the problem, if someone can confirm that would be awesome. Turns out if the number of groups the user belongs to exceeds seven (7), LDAP authentication fails. I arrived at this conclusion by creating a new user (by copying the failing user) and removing the groups, one by one (testing in between each removal) until I was successful.
Unfortunately, I was not able to successfully reproduce the problem in the reverse (i.e., by adding the same user to eight (8) security groups). I even added it to more groups, and authentication still succeeds. Which seems to suggest that something is cached on the Linux side. I performed some additional tests as follows:
TEST #1:
TEST #2:
TEST #3:
I repeated the above tests until I got to TEST #9 (where the user was added to fifteen security groups), and still couldn't reproduce the problem.
I attempted to read through the plugin's code on GitHub, but couldn't make sense of it (due to my limited understanding of JavaScript).
So, a couple of questions:
Good-day Folks,
I'm having an issue with LDAP login against an Active Directory domain controller. Fortunately, I am the only admin, so it hasn't been a major problem (since I can still login with a local account). Anybody else out there running into this problem?
MY ENVIRONMENT:
xo-server 5.113.0 / Xen Orchestra, commit c0465 / xo-web 5.116.0
I've read through the following posts and confirmed that my settings are correct and should be working:
Here's the output of the test-cli.js script for my existing account and a test account I created (after the problem started
FOR MY USER ACCOUNT (kagbasi)
root@mydomain-SV-XO1:/opt/xo/xo-server/node_modules/xo-server-auth-ldap/dist# ./test-cli.js ldap.cache.conf
? URI ldap://dc01.mydomain.net
? fill optional Certificate Authorities? No
? fill optional Check certificate? No
? fill optional Use StartTLS? No
? Base OU=MyOU,DC=mydomain,DC=net
? fill optional Credentials? Yes
? Credentials > dn xxXOC@mydomain.net
? Credentials > password ***
? fill optional User filter? Yes
? User filter (&(sAMAccountName={{name}})(memberOf=CN=IT_Linux_Admins,OU=Groups,OU=MyOU,DC=mydomain,DC=net))
? fill optional ID attribute? Yes
? ID attribute sAMAccountName
? fill optional Synchronize groups? No
configuration saved in ./ldap.cache.conf
? Username kagbasi
? Password [hidden]
2023-05-14T08:33:48.354Z xo:xo-server-auth-ldap DEBUG attempting to bind with as xxXOC@mydomain.net...
2023-05-14T08:33:48.369Z xo:xo-server-auth-ldap DEBUG successfully bound as xxXOC@mydomain.net
2023-05-14T08:33:48.369Z xo:xo-server-auth-ldap DEBUG searching for entries...
2023-05-14T08:33:48.375Z xo:xo-server-auth-ldap DEBUG 1 entries found
2023-05-14T08:33:48.375Z xo:xo-server-auth-ldap DEBUG attempting to bind as CN=Agbasi\, Kismet,OU=General Users,OU=Users,OU=MyOU,DC=mydomain,DC=net
2023-05-14T08:33:48.378Z xo:xo-server-auth-ldap DEBUG failed to bind as CN=Agbasi\, Kismet,OU=General Users,OU=Users,OU=MyOU,DC=mydomain,DC=net: 80090308: LdapErr: DSID-0C090434, comment: AcceptSecurityContext error, data 569, v4f7c Code: 0x31
2023-05-14T08:33:48.378Z xo:xo-server-auth-ldap DEBUG could not authenticate kagbasi
root@mydomain-SV-XO1:/opt/xo/xo-server/node_modules/xo-server-auth-ldap/dist#
FOR A TEST USER ACCOUNT (test123)
root@mydomain-SV-XO1:/opt/xo/xo-server/node_modules/xo-server-auth-ldap/dist# ./test-cli.js ldap.cache.conf
? URI ldap://dc01.mydomain.net
? fill optional Certificate Authorities? No
? fill optional Check certificate? No
? fill optional Use StartTLS? No
? Base OU=MyOU,DC=mydomain,DC=net
? fill optional Credentials? Yes
? Credentials > dn xxXOC@mydomain.net
? Credentials > password ***
? fill optional User filter? Yes
? User filter (&(sAMAccountName={{name}})(memberOf=CN=IT_Linux_Admins,OU=Groups,OU=MyOU,DC=mydomain,DC=net))
? fill optional ID attribute? Yes
? ID attribute sAMAccountName
? fill optional Synchronize groups? No
configuration saved in ./ldap.cache.conf
? Username test123
? Password [hidden]
2023-05-14T08:43:05.780Z xo:xo-server-auth-ldap DEBUG attempting to bind with as xxXOC@mydomain.net...
2023-05-14T08:43:05.795Z xo:xo-server-auth-ldap DEBUG successfully bound as xxXOC@mydomain.net
2023-05-14T08:43:05.795Z xo:xo-server-auth-ldap DEBUG searching for entries...
2023-05-14T08:43:05.801Z xo:xo-server-auth-ldap DEBUG 1 entries found
2023-05-14T08:43:05.801Z xo:xo-server-auth-ldap DEBUG attempting to bind as CN=Test User,OU=General Users,OU=Users,OU=MyOU,DC=mydomain,DC=net
2023-05-14T08:43:05.803Z xo:xo-server-auth-ldap INFO successfully bound as CN=Test User,OU=General Users,OU=Users,OU=MyOU,DC=mydomain,DC=net => test123 authenticated
2023-05-14T08:43:05.803Z xo:xo-server-auth-ldap DEBUG {
"dn": "CN=Test User,OU=General Users,OU=Users,OU=MyOU,DC=mydomain,DC=net",
"objectClass": [
"top",
"person",
"organizationalPerson",
"user"
],
"cn": "Test User",
"sn": "User",
"givenName": "Test",
"distinguishedName": "CN=Test User,OU=General Users,OU=Users,OU=MyOU,DC=mydomain,DC=net",
"instanceType": "4",
"whenCreated": "20230514083604.0Z",
"whenChanged": "20230514083657.0Z",
"displayName": "Test User",
"uSNCreated": "696212",
"memberOf": "CN=IT_Linux_Admins,OU=Groups,OU=MyOU,DC=mydomain,DC=net",
"uSNChanged": "696231",
"name": "Test User",
"objectGUID": "~\b\u000e��\u001f�E����\r�,�",
"userAccountControl": "512",
"badPwdCount": "0",
"codePage": "0",
"countryCode": "0",
"badPasswordTime": "0",
"lastLogoff": "0",
"lastLogon": "0",
"pwdLastSet": "133285269646375752",
"primaryGroupID": "513",
"objectSid": "\u0001\u0005\u0000\u0000\u0000\u0000\u0000\u0005\u0015\u0000\u0000\u0000�A�\u0015�d�G�:��`\u0006\u0000\u0000",
"accountExpires": "9223372036854775807",
"logonCount": "0",
"sAMAccountName": "test123",
"sAMAccountType": "805306368",
"userPrincipalName": "test123@mydomain.net",
"objectCategory": "CN=Person,CN=Schema,CN=Configuration,DC=mydomain,DC=net",
"dSCorePropagationData": "16010101000000.0Z",
"lastLogonTimestamp": "133285270174344684"
}
root@mydomain-SV-XO1:/opt/xo/xo-server/node_modules/xo-server-auth-ldap/dist#
@Danp I tried it, and the OS gave me a slap on the wrist...lol 
root@WGSDAC-SV-XO1:~# resize2fs /dev/xvda1
resize2fs 1.46.2 (28-Feb-2021)
The filesystem is already 2371072 (4k) blocks long. Nothing to do!
So I cleaned out the yarn cache as well as the apt cache, and this has jointly reclaimed about 3GiB of space.
root@WGSDAC-SV-XO1:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 3.9G 0 3.9G 0% /dev
tmpfs 794M 528K 793M 1% /run
/dev/xvda1 8.9G 5.3G 3.1G 63% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 794M 0 794M 0% /run/user/1000
Gonna attempt the XO update again and see if it succeeds, while I study up on doing the partition resize safely. Please keep the suggestions coming - they're quite helpful in growing my knowledge of Linux.