Unable to log in using ldap after a app name change #3930

Closed
opened 2026-02-05 07:53:47 +03:00 by OVERLORD · 3 comments
Owner

Originally created by @Alakadoo on GitHub (Jul 25, 2023).

Attempted Debugging

  • I have read the debugging page

Searched GitHub Issues

  • I have searched GitHub for the issue.

Describe the Scenario

We have been using bookstack for some weeks now with ldap authentification enabled, everything was working fine.
Then we decided to rename the webiste, so I changed the name in the .env file, in the httpd conf file, in the web config panel page, did a new certificate to match the new name, and ran the php artisan bookstack:update-url.

But we are now unable to log in to existing accounts using ldap auth.
The ldap configuration is fine, if I create a new ldap user I can login to bookstack, but an existing user prior to renaming cannot log in after the rename, it shows the error "these credentials do not match our records", I checked the credentials multiple times they are fine.
I logged in with local admin account and deleted our registered ldap users thinking the accounts would recreate fine since I could login with new ldap account, but it did not work, same error. I checked in the users table of the bookstack database, the account are deleted.

The laravel.log, error.log and access.log show nothing related to the authentification error, turning on app_debug doesn't add any information to the error.
I'm out of ideas, I have trouble finding the relationship between the website rename and ldap authentification.

Does anyone have an idea to resolve this ?

Exact BookStack Version

23.06.2

Log Content

No response

PHP Version

8.0

Hosting Environment

Oracle 8

Originally created by @Alakadoo on GitHub (Jul 25, 2023). ### Attempted Debugging - [X] I have read the debugging page ### Searched GitHub Issues - [X] I have searched GitHub for the issue. ### Describe the Scenario We have been using bookstack for some weeks now with ldap authentification enabled, everything was working fine. Then we decided to rename the webiste, so I changed the name in the .env file, in the httpd conf file, in the web config panel page, did a new certificate to match the new name, and ran the php artisan bookstack:update-url. But we are now unable to log in to existing accounts using ldap auth. The ldap configuration is fine, **if I create a new ldap user I can login to bookstack**, but an existing user prior to renaming cannot log in after the rename, it shows the error "these credentials do not match our records", I checked the credentials multiple times they are fine. I logged in with local admin account and deleted our registered ldap users thinking the accounts would recreate fine since I could login with new ldap account, but it did not work, same error. I checked in the users table of the bookstack database, the account are deleted. The laravel.log, error.log and access.log show nothing related to the authentification error, turning on app_debug doesn't add any information to the error. I'm out of ideas, I have trouble finding the relationship between the website rename and ldap authentification. Does anyone have an idea to resolve this ? ### Exact BookStack Version 23.06.2 ### Log Content _No response_ ### PHP Version 8.0 ### Hosting Environment Oracle 8
OVERLORD added the 🐕 Support label 2026-02-05 07:53:47 +03:00
Author
Owner

@ssddanbrown commented on GitHub (Jul 25, 2023):

it shows the error "these credentials do not match our records"

I'm not familiar with that exact error, could you screenshot the exact error you see in this process? Just so I can understand better where it's coming from.

Really, there shouldn't be any kind of direct link between the app URL and LDAP auth functionality.
Did anything change on the LDAP/user side of things? For example, change of email domain for those users? or new LDAP system with same users imported?

@ssddanbrown commented on GitHub (Jul 25, 2023): > it shows the error "these credentials do not match our records" I'm not familiar with that exact error, could you screenshot the exact error you see in this process? Just so I can understand better where it's coming from. Really, there shouldn't be any kind of direct link between the app URL and LDAP auth functionality. Did anything change on the LDAP/user side of things? For example, change of email domain for those users? or new LDAP system with same users imported?
Author
Owner

@Alakadoo commented on GitHub (Jul 25, 2023):

Here is the error.
I enabled "LDAP_DUMP_USER_DETAILS" to get some more informations, and the json in return rightfully show all fields of my AD account, so there don't seem to be any communication problem between bookstack and AD.

Nothing changed in the AD side of things domain emails are the same, cn and samaccountname are the same too

It may be a coincidence I don't see any link either, yet I am unable to connect since. I have checked the ldap part of .env thinking maybe I've by mistake changed something, I've redone it from scratch but still nothing changed.
I also don't understand why a new AD user can connect, yet an existing user cannot, even after I deleted his account bookstack side and removed his entry in the users table of the database.

@Alakadoo commented on GitHub (Jul 25, 2023): Here is the error. I enabled "LDAP_DUMP_USER_DETAILS" to get some more informations, and the json in return rightfully show all fields of my AD account, so there don't seem to be any communication problem between bookstack and AD. Nothing changed in the AD side of things domain emails are the same, cn and samaccountname are the same too It may be a coincidence I don't see any link either, yet I am unable to connect since. I have checked the ldap part of .env thinking maybe I've by mistake changed something, I've redone it from scratch but still nothing changed. I also don't understand why a new AD user can connect, yet an existing user cannot, even after I deleted his account bookstack side and removed his entry in the users table of the database.
Author
Owner

@Alakadoo commented on GitHub (Jul 25, 2023):

Nethermind, a colleague did not think it was useful to notify me that he had touched the ntlm connection delegation authorizations on AD.
Resolved, thank you for your help :)

@Alakadoo commented on GitHub (Jul 25, 2023): Nethermind, a colleague did not think it was useful to notify me that he had touched the ntlm connection delegation authorizations on AD. Resolved, thank you for your help :)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#3930