LDAP groups: use specific groups DN instead of memberOf attribute #3954

New Issue

OVERLORD · 2026-02-05T07:57:13+03:00

OVERLORD commented

2026-02-05 07:57:13 +03:00

Originally created by @jko-nic on GitHub (Aug 7, 2023).

Describe the feature you'd like

Currently, LDAP group support depends on using LDAP_GROUP_ATTRIBUTE (as written in wiki), which has to be set for every user (and contain groups which is the user member of. Our OpenLDAP installation uses different approach - we have ou=People (with employees) and ou=Group containing groups and their members. For every other (10+) system this is not problematic and we can set that group membership information is located in ou=Group.

I know we can set up memberOf overlay, but doing this change to such critical part of our infrastructure because of wiki software we are currently testing seems, honestly, like a good reason to choose something else. So I would like to know if there is something, such as undocumented settings or planning feature solving this particular problem an the part of BookStack (for example adding something like LDAP_GROUP_DN option to search groups within).

Describe the benefits this would bring to existing BookStack users

Avoid changes in OpenLDAP schema, using dedicated groups DN to maintain clean LDAP schema without "duplicated" group membership information.

Can the goal of this request already be achieved via other means?

Partially yes, but it requires changing LDAP schema, which is really not desired.

Have you searched for an existing open/closed issue?

I have searched for existing issues and none cover my fundemental request

How long have you been using BookStack?

0 to 6 months

Additional context

We are currently testing Bookstack and installed v23.06.2.

Originally created by @jko-nic on GitHub (Aug 7, 2023). ### Describe the feature you'd like Currently, LDAP group support depends on using `LDAP_GROUP_ATTRIBUTE` (as written in [wiki](https://www.bookstackapp.com/docs/admin/ldap-auth/)), which has to be set for every user (and contain groups which is the user member of. Our OpenLDAP installation uses different approach - we have `ou=People` (with employees) and `ou=Group` containing groups and their members. For every other (10+) system this is not problematic and we can set that group membership information is located in `ou=Group`. I know we can set up `memberOf` overlay, but doing this change to such critical part of our infrastructure because of wiki software we are currently testing seems, honestly, like a good reason to choose something else. So I would like to know if there is something, such as undocumented settings or planning feature solving this particular problem an the part of BookStack (for example adding something like `LDAP_GROUP_DN` option to search groups within). ### Describe the benefits this would bring to existing BookStack users Avoid changes in OpenLDAP schema, using dedicated groups DN to maintain clean LDAP schema without "duplicated" group membership information. ### Can the goal of this request already be achieved via other means? Partially yes, but it requires changing LDAP schema, which is really not desired. ### Have you searched for an existing open/closed issue? - [X] I have searched for existing issues and none cover my fundemental request ### How long have you been using BookStack? 0 to 6 months ### Additional context We are currently testing Bookstack and installed v23.06.2.

OVERLORD added the 🔨 Feature Request 🚪 Authentication labels 2026-02-05 07:57:13 +03:00

OVERLORD closed this issue

2026-02-05 07:57:15 +03:00

OVERLORD commented

2026-02-05 07:57:21 +03:00

@ssddanbrown commented on GitHub (Aug 8, 2023):

Thanks for the request @jko-nic.

To be perfectly honest, I really wouldn't want to add additional options for LDAP group handling.
From requests and experiences, the memberOf style scheme is most commonplace and desired for this kind of use case, and I don't think this specific DN-style of group management has been requested before.
I wouldn't want to increase the scope of what we're supporting with some significant desire/demand, and based on the lack of similar request over the years, I don't think that demand is there.

I would however be open to adding a logical theme system event allowing custom group handling where desired, but use of this would likely require PHP knowledge on your side to implement and maintain going forward.

@ssddanbrown commented on GitHub (Aug 8, 2023): Thanks for the request @jko-nic. To be perfectly honest, I really wouldn't want to add additional options for LDAP group handling. From requests and experiences, the `memberOf` style scheme is most commonplace and desired for this kind of use case, and I don't think this specific DN-style of group management has been requested before. I wouldn't want to increase the scope of what we're supporting with some significant desire/demand, and based on the lack of similar request over the years, I don't think that demand is there. I would however be open to adding a [logical theme system](https://github.com/BookStackApp/BookStack/blob/development/dev/docs/logical-theme-system.md) event allowing custom group handling where desired, but use of this would likely require PHP knowledge on your side to implement and maintain going forward.

OVERLORD commented

2026-02-05 07:57:26 +03:00

@jko-nic commented on GitHub (Aug 9, 2023):

Thank you @ssddanbrown for your comment,
your reaction was quick and complete, so I am now more able to understand your point of view. Managing internally duplicate structure od LDAP groups handling seems like a big no-go, especially when all use cases seems covered and nobody else had this request before.

Thank you very much for your time and attention, the rest is on our own so I am closing this issue.

@jko-nic commented on GitHub (Aug 9, 2023): Thank you @ssddanbrown for your comment, your reaction was quick and complete, so I am now more able to understand your point of view. Managing internally duplicate structure od LDAP groups handling seems like a big no-go, especially when all use cases seems covered and nobody else had this request before. Thank you very much for your time and attention, the rest is on our own so I am closing this issue.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#3954