BookStackApp
LDAP integration not working for a single user
Attempted Debugging
- [X] I have read the debugging page
Searched GitHub Issues
- [X] I have searched GitHub for the issue.
Describe the Scenario
I am running a Bookstack instance integrated with a local AD.
Things are working as expected but for one single user that I can not seem to be able to link to our AD. If I log in with LDAP_DUMP_USER_DETAILS=true I get the expected details. ie
details_from_ldap
0 "cn"
1 "objectguid"
2 "mail"
cn
0 "someuser"
count 1
objectguid
0 "8???\u001a?I?D????`\u001e"
count 1
mail
0 "[email protected]"
count 1
count 3
dn "CN=someuser,OU=MUR,OU=CE,DC=domain,DC=local"
details_bookstack_parsed
uid "38e2c0ea9e1y8349aa44c5e0f6e6601e"
name "someuser"
dn "CN=someuser,OU=MUR,OU=CE,DC=domain,DC=local"
email "[email protected]"
avatar null
but logging with the exact same credentials does systematically end up with a "These credentials do not match our records." error.
Not quite sure what could be causing this (other users are just working as expected).
Exact BookStack Version
v23.05.2
Log Content
No response
Hosting Environment
Self hosted Debian 11 (bullseye) VM - patched Jan 28, 2024
Things are working as expected but for one single user that I can not seem to be able to link to our AD.
Does a user, with that same email address, already exist in BookStack? If so, have you done anything to link the BookStack user to the LDAP user?
Does a user, with that same email address, already exist in BookStack?
Nope
If so, have you done anything to link the BookStack user to the LDAP user?
I have, however, tried to create the user manually and enter the returned UID as "external authentication ID" - The user still can't logon.
Any further suggestion much appreciated.
In particular which log(s) should I observe ?
To be honest, since you're seeing a user dumped, and that error, it really points to the password being wrong for that matched user.
You could try using something like the ldapsearch command, ideally from the same host as BookStack, to bind as that user, with a password, under the same baseDN, and see if that works without error.
Since there's been no further follow-up since my last message I'll close this off. Feel free to respond to my previous comment though and this can be re-opened if needed.