ldap authentication not working

[chymian]

@nebulon it is as I described and not working for any of the users in that group. all other apps used with this group are working fine.
from the history: I had an empty jellyfin install a couple of month ago, deleted it (unused) because at that time I dropped the idea around the initial usecase. now, a new usecase came up and I installed it new.
with the second fresh install I have these pbls.

@mehdi, look at the log & you see that there is a username used, not a email. (and shouldn't it work with both?)

the only thing I changed, after it was not working, was the servername in the general-settings, from an UUID to the fqdn, in the hope it would be better. that's all.

[nebulon]

@chymian does that username you tried contain any special characters which might fail here? Also can you install a fresh instance, letting all Cloudron users have access and then try with that username again? Just trying to narrow this down here, since I cannot reproduce the failure.

[chymian]

@nebulon

1. the test-userame is all eng. ascii-letters, as you can see in the log: "itsme"
2. opened up the existing install to all users, no change

since the tar-backup to a minio S3 running @ hetzner-VM to a cifs-connected storage-box is veeeery slow (~1MBps), we have to wait for that to finish…

3. to see the result of a new instance installed, diff. domain with all users allowed:

4. meanwhile, is there a ldap query/cat which I can use from inside the container to check the connectivity?

[nebulon]

@chymian I guess you can use the following command in the webterminal to check how many users are returned for that app through LDAP to test connection:

ldapsearch -H ${CLOUDRON_LDAP_URL} -D ${CLOUDRON_LDAP_BIND_DN} -w ${CLOUDRON_LDAP_BIND_PASSWORD}

[chymian]

@nebulon said in ldap authentication not working:

ldapsearch -H ${CLOUDRON_LDAP_URL} -D ${CLOUDRON_LDAP_BIND_DN} -w ${CLOUDRON_LDAP_BIND_PASSWORD}

root@44432c3c-9b9d-4a24-96d7-1cc2130f3ec2:/# ldapsearch -H ${CLOUDRON_LDAP_URL} -D ${CLOUDRON_LDAP_BIND_DN} -w ${CLOUDRON_LDAP_BIND_PASSWORD}
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object
text: No tree found for: 

# numResponses: 1

[nebulon]

@chymian oh sorry my snippet was somehow missing the last argument, it should be:

ldapsearch -H ${CLOUDRON_LDAP_URL} -D ${CLOUDRON_LDAP_BIND_DN} -w ${CLOUDRON_LDAP_BIND_PASSWORD} -b ${CLOUDRON_LDAP_USERS_BASE_DN}

[chymian]

@nebulon said in ldap authentication not working:

@chymian oh sorry my snippet was somehow missing the last argument, it should be:

ldapsearch -H ${CLOUDRON_LDAP_URL} -D ${CLOUDRON_LDAP_BIND_DN} -w ${CLOUDRON_LDAP_BIND_PASSWORD} -b ${CLOUDRON_LDAP_USERS_BASE_DN}

that works, shows all users in that group.

[chymian]

if I chose another group, the results change accordingly.
so on that level, LDAP User/Group query seems to work.

[mehdi]

@chymian Did it not work as soon as you installed the app ? Or did it use to work then stopped sometime ? Maybe after an app update or something ?

[chymian]

@mehdi said in ldap authentication not working:

@chymian Did it not work as soon as you installed the app ? Or did it use to work then stopped sometime ? Maybe after an app update or something ?

for the first install, I cannot say.
for the second - actual - install, it didn't work from the beginning.

[mehdi]

@chymian At this point, the only thing left to try would be another instance of the app.

[chymian]

@nebulon, @mehdi

since the tar-backup to a minio S3 running @ hetzner-VM to a cifs-connected storage-box is veeeery slow (~1MBps), we have to wait for that to finish…

to see the result of a new instance installed, diff. domain with all users allowed:

the new instance on a diff. domain, works as expected:

• all users: ok
• group only: ok

since all data (>300G) are on external (S3) volumes, which are fstab-mounted onto the system with the fabulous goofys and provided to the app via volumes, I reinstalled the primary instance, same fqdn, same LDAP-group: every seems to work now.

the culprit is left unidentified!
thx for your time & support, guys

[nebulon]

@chymian any chance you may have tweaked some configs or so on the other instance, which may have caused an issue?

[chymian]

@nebulon

the only thing I changed, after it was not working, was the servername in the general-settings, from an UUID to the fqdn, in the hope it would be better. that's all.

sorry, I double thought of that also, but no, I haven't. I remember that after creating the instance I did set up my usual admin account & then had to add my personal user-account manually, I assumed there was no LDAP-connection (like wallabag), but did'nt check on it due to timely-restrictions. (means also NO time to fiddle with the setup)
only after I added more users to it I checked for an LDAP-plugin and saw it is existent, but was not working. also - due to timely-restirctions - not investigating why it didn't work out of the box.
since I had some time now, I started investigating, especially, since I had to create more and more user-accounts all way long, as the provided media gained on interests.

after 35 years of systemadministration, I know, sometimes unexplainable things happen – it's just not always straight forward as it everyone would suspect.

hab's gut derweil
cheers
günter