Enabling LDAP lost admin access #1649

New Issue

OVERLORD · 2026-02-05T01:30:28+03:00

OVERLORD commented

2026-02-05 01:30:28 +03:00

Originally created by @kabaga on GitHub (Apr 14, 2020).

Describe the bug
According the Bookstackapp instruction, to enable LDAP, the LDAP parameters need to be added to the .env file. The issue that I am having is when I login to the web UI using the local Bookstack admin account, then change the AUTH_METHOD from standard to ldap. Bookstack logs me out. When I try to login again, Bookstack gives me an error stating "These credentials do not match our records."

LDAP works because I can login with my ldap user account, but no admin privilege.

I couldn't get the LDAPS to work at all.

Steps To Reproduce
Steps to reproduce the behavior:

Add the LDAP parameters to the .env file
Change the AUTH_METHOD to standard
On the Bookstack web UI, login using the local admin account
Change the AUTH_METHOD to ldap
Refresh the web UI page
Bookstack bring you back to the login page
Login with the local admin account will fail and gives out error message "These credentials do not match our records."
Login with ldap account works, but no admin level access

Expected behavior
Step 6 should not kick me out and should allow me to continue working on ‘External Authentication ID’

Screenshots
n/a

Your Configuration (please complete the following information):

Exact BookStack Version (Found in settings): v0.28.3
PHP Version: 7.3.16 according to the containers php -v
Hosting Method (Nginx/Apache/Docker): Docker container from Linuxserver.io

Additional context
I am using Univention as my LDAP server. Here is the .env LDAP parameters.

AUTH_METHOD=ldap
LDAP_SERVER=10.0.7.40:7389
#LDAP_SERVER=ldaps://10.0.7.40:7636
LDAP_BASE_DN=dc=example,dc=com
LDAP_DN=uid=bookstack,cn=users,dc=example,dc=com
LDAP_PASS=password
LDAP_USER_FILTER=(&(uid=${user}))
LDAP_VERSION=3
LDAP_ID_ATTRIBUTE=uid
LDAP_EMAIL_ATTRIBUTE=mail
LDAP_DISPLAY_NAME_ATTRIBUTE=uid
LDAP_USER_TO_GROUPS=true
LDAP_GROUP_ATTRIBUTE="memberOf"
LDAP_REMOVE_FROM_GROUPS=false
LDAP_AUTO_CONFIRM_EMAIL=true
LDAP_TLS_INSECURE=false
LDAP_FOLLOW_REFERRALS=true
APP_DEBUG=true

Originally created by @kabaga on GitHub (Apr 14, 2020). **Describe the bug** According the Bookstackapp [instruction](https://www.bookstackapp.com/docs/admin/ldap-auth/), to enable LDAP, the LDAP parameters need to be added to the .env file. The issue that I am having is when I login to the web UI using the local Bookstack admin account, then change the AUTH_METHOD from standard to ldap. Bookstack logs me out. When I try to login again, Bookstack gives me an error stating "These credentials do not match our records." LDAP works because I can login with my ldap user account, but no admin privilege. I couldn't get the LDAPS to work at all. **Steps To Reproduce** Steps to reproduce the behavior: 1. Add the LDAP parameters to the .env file 2. Change the AUTH_METHOD to standard 3. On the Bookstack web UI, login using the local admin account 4. Change the AUTH_METHOD to ldap 5. Refresh the web UI page 6. Bookstack bring you back to the login page 7. Login with the local admin account will fail and gives out error message "These credentials do not match our records." 8. Login with ldap account works, but no admin level access **Expected behavior** Step 6 should not kick me out and should allow me to continue working on ‘External Authentication ID’ **Screenshots** n/a **Your Configuration (please complete the following information):** - Exact BookStack Version (Found in settings): v0.28.3 - PHP Version: 7.3.16 according to the containers php -v - Hosting Method (Nginx/Apache/Docker): Docker container from Linuxserver.io **Additional context** I am using Univention as my LDAP server. Here is the .env LDAP parameters. AUTH_METHOD=ldap LDAP_SERVER=10.0.7.40:7389 #LDAP_SERVER=ldaps://10.0.7.40:7636 LDAP_BASE_DN=dc=example,dc=com LDAP_DN=uid=bookstack,cn=users,dc=example,dc=com LDAP_PASS=password LDAP_USER_FILTER=(&(uid=${user})) LDAP_VERSION=3 LDAP_ID_ATTRIBUTE=uid LDAP_EMAIL_ATTRIBUTE=mail LDAP_DISPLAY_NAME_ATTRIBUTE=uid LDAP_USER_TO_GROUPS=true LDAP_GROUP_ATTRIBUTE="memberOf" LDAP_REMOVE_FROM_GROUPS=false LDAP_AUTO_CONFIRM_EMAIL=true LDAP_TLS_INSECURE=false LDAP_FOLLOW_REFERRALS=true APP_DEBUG=true

OVERLORD added the 🐛 Bug 🚪 Authentication 🏭 Back-End labels 2026-02-05 01:30:28 +03:00

OVERLORD closed this issue

2026-02-05 01:30:29 +03:00

OVERLORD commented

2026-02-05 01:30:32 +03:00

@ssddanbrown commented on GitHub (Apr 14, 2020):

Hi @kabaga
Thanks for the detailed report and apologies about this. Just tested and can confirm the problem here. Looks like some work I did in v0.28, to better separate & align the authentication systems, has had the side-effect of producing this awkward behaviour.

I'll look to update this soon.
Until then, as a work-around, You can alternatively update the "External Authentication ID" in the database directly. You can find this on the users table, on the external_auth_id column. You could do this to at least gain yourself access as an LDAP-login admin so that you can then login and continue via the interface as normal.

@ssddanbrown commented on GitHub (Apr 14, 2020): Hi @kabaga Thanks for the detailed report and apologies about this. Just tested and can confirm the problem here. Looks like some work I did in `v0.28`, to better separate & align the authentication systems, has had the side-effect of producing this awkward behaviour. I'll look to update this soon. Until then, as a work-around, You can alternatively update the "External Authentication ID" in the database directly. You can find this on the `users` table, on the `external_auth_id` column. You could do this to at least gain yourself access as an LDAP-login admin so that you can then login and continue via the interface as normal.

OVERLORD commented

2026-02-05 01:30:36 +03:00

@ssddanbrown commented on GitHub (Apr 25, 2020):

Within 519283e643, I've updated the authentication behaviour so that admin users will be authenticated across all authentication types upon login. This will be part of the next BookStack patch release.

@ssddanbrown commented on GitHub (Apr 25, 2020): Within 519283e643f9697952d49c7009dd9e9745cb4319, I've updated the authentication behaviour so that admin users will be authenticated across all authentication types upon login. This will be part of the next BookStack patch release.

OVERLORD commented

2026-02-05 01:30:38 +03:00

@eoli3n commented on GitHub (Apr 3, 2024):

It seems that this is not working, I just created a admin user with

$ php artisan bookstack:create-admin --email="admin@bookstack-prep.domain.fr" --name="admin" --password="**********"

And when I try to login with AUTH_METHOD=ldap, I get informations doesn't match any account.

@eoli3n commented on GitHub (Apr 3, 2024): It seems that this is not working, I just created a admin user with ``` $ php artisan bookstack:create-admin --email="admin@bookstack-prep.domain.fr" --name="admin" --password="**********" ``` And when I try to login with ``AUTH_METHOD=ldap``, I get ``informations doesn't match any account``.

OVERLORD commented

2026-02-05 01:30:44 +03:00

@ssddanbrown commented on GitHub (Apr 3, 2024):

@eoli3n You'd need to change to AUTH_METHOD=standard temporarily to sign in via an email/password account like that.

@ssddanbrown commented on GitHub (Apr 3, 2024): @eoli3n You'd need to change to `AUTH_METHOD=standard` temporarily to sign in via an email/password account like that.

OVERLORD commented

2026-02-05 01:30:48 +03:00

@eoli3n commented on GitHub (Apr 3, 2024):

No way to force standard auth only for a admin account ? Code-side I mean.
Any plan to fix this ? It seems to be a pretty important issue.

EDIT : when i switch to standard, I now get "email should be a valid email address".

EDIT : when i try to use my email, "already used"
Bookstack is a bit capricious about authentication
Why isn't it possible to put on list box, to choose "local" or "ldap", as we do in the config file, on the login screen ?

EDIT : Why would bookstack force email authentication when using standard auth.
Too much complications, IMO this should be a core feature, simple to manage.

Ability to:

switch authentication methods from login screen
authenticate with username or email with standard method
create an admin account without email address
use email twice, admin is a real person, that already have another user account

@eoli3n commented on GitHub (Apr 3, 2024): No way to force standard auth only for a admin account ? Code-side I mean. Any plan to fix this ? It seems to be a pretty important issue. --- EDIT : when i switch to ``standard``, I now get "email should be a valid email address". --- EDIT : when i try to use my email, "already used" Bookstack is a bit capricious about authentication Why isn't it possible to put on list box, to choose "local" or "ldap", as we do in the config file, on the login screen ? --- EDIT : Why would bookstack force email authentication when using ``standard`` auth. Too much complications, IMO this should be a core feature, simple to manage. Ability to: - switch authentication methods from login screen - authenticate with username or email with ``standard`` method - create an admin account without email address - use email twice, admin is a real person, that already have another user account

OVERLORD commented

2026-02-05 01:30:52 +03:00

@ssddanbrown commented on GitHub (Apr 3, 2024):

when i switch to standard, I now get "email should be a valid email address".

@eoli3n You need to load the login page with AUTH_METHOD=standard then login with your admin account, then revert back AUTH_METHOD.

Why isn't it possible to put on list box, to choose "local" or "ldap", as we do in the config file, on the login screen ?
Any plan to fix this ? It seems to be a pretty important issue.

Like most things, it is technically possible but would that introduce complications and additional concerns. I believe there is an open request for simultaneous main auth methods via another request.
I don't currently see an active issue here, so no plans to fix anything.

Why would bookstack force email authentication when using standard auth.
when i try to use my email, "already used"

I'm not sure what this means. standard auth is email auth.
You shouldn't get any kind of already used warning with standard auth login.

@ssddanbrown commented on GitHub (Apr 3, 2024): > when i switch to standard, I now get "email should be a valid email address". @eoli3n You need to load the login page with `AUTH_METHOD=standard` then login with your admin account, then revert back `AUTH_METHOD`. > Why isn't it possible to put on list box, to choose "local" or "ldap", as we do in the config file, on the login screen ? > Any plan to fix this ? It seems to be a pretty important issue. Like most things, it is technically possible but would that introduce complications and additional concerns. I believe there is an open request for simultaneous main auth methods via another request. I don't currently see an active issue here, so no plans to fix anything. > Why would bookstack force email authentication when using standard auth. > when i try to use my email, "already used" I'm not sure what this means. standard auth is email auth. You shouldn't get any kind of `already used` warning with standard auth login.

OVERLORD commented

2026-02-05 01:30:55 +03:00

@eoli3n commented on GitHub (Apr 3, 2024):

I successfully authenticated with the local admin account.
The already used is at creation the local admin account with php artisan ....

I connect with admin account everyday, when I miss some permissions.
In the current state, I need then one ldap admin account to easily connect without breaking production (when changing to standard), and a local admin account when AD or network is down. Seems strange to me, things should be simpler.

standard auth is email auth.

Because you chose it to be :) Why would ldap auth be username (here we have choice yes), and standard auth something else ?
It forces to set an email adress, which should be optionnal IMO.

@eoli3n commented on GitHub (Apr 3, 2024): I successfully authenticated with the local admin account. The ``already used`` is at creation the local admin account with ``php artisan ...``. I connect with admin account everyday, when I miss some permissions. In the current state, I need then one ldap admin account to easily connect without breaking production (when changing to ``standard``), and a local admin account when AD or network is down. Seems strange to me, things should be simpler. > standard auth is email auth. Because you chose it to be :) Why would ldap auth be username (here we have choice yes), and standard auth something else ? It forces to set an email adress, which should be optionnal IMO.

OVERLORD referenced this issue

2026-02-05 02:20:12 +03:00

Update WYSIWYG editor to TinyMCE 5 #1961

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1649