LDAP Group Sync with Domain Restriction Turned ON #1698

Closed
opened 2026-02-05 01:39:10 +03:00 by OVERLORD · 4 comments
Owner

Originally created by @mikeyz24 on GitHub (Apr 30, 2020).

I'm not sure if this is a bug or i'm doing something wrong...
I'm trying to setup AD group sync but it appears that my AD group (role) is not being assigned to new accounts when Domain Restriction setting is turned on.

When a new user signs in with their domain credentials, they always get assigned the Role that is defined in the dropdown for "Default user roler after registration" and the role that is in AD does not get assigned.

If I remove the domain restriction, when a new user signs in, they get assigned the Group they are part of in AD and ALSO the role that is defined in "default user role after registration".

How do I make it so that only the role that the user is a part of in AD gets assigned when they first login?

I'm running v0.29.1
My .ENV file for LDAP has the following settings:

LDAP_USER_FILTER=(&(sAMAccountName=${user}))
LDAP_VERSION=3
LDAP_USER_TO_GROUPS=true
LDAP_GROUP_ATTRIBUTE="memberOf"
LDAP_REMOVE_FROM_GROUPS=true
LDAP_DISPLAY_NAME_ATTRIBUTE=cn
Originally created by @mikeyz24 on GitHub (Apr 30, 2020). I'm not sure if this is a bug or i'm doing something wrong... I'm trying to setup AD group sync but it appears that my AD group (role) is not being assigned to new accounts when Domain Restriction setting is turned on. When a new user signs in with their domain credentials, they always get assigned the Role that is defined in the dropdown for "Default user roler after registration" and the role that is in AD does not get assigned. If I remove the domain restriction, when a new user signs in, they get assigned the Group they are part of in AD and ALSO the role that is defined in "default user role after registration". How do I make it so that only the role that the user is a part of in AD gets assigned when they first login? I'm running v0.29.1 My .ENV file for LDAP has the following settings: ``` LDAP_USER_FILTER=(&(sAMAccountName=${user})) LDAP_VERSION=3 LDAP_USER_TO_GROUPS=true LDAP_GROUP_ATTRIBUTE="memberOf" LDAP_REMOVE_FROM_GROUPS=true LDAP_DISPLAY_NAME_ATTRIBUTE=cn ```
OVERLORD added the 🐛 Bug🚪 Authentication🏭 Back-End labels 2026-02-05 01:39:10 +03:00
Author
Owner

@ssddanbrown commented on GitHub (May 2, 2020):

Thanks for reporting @mikeyz24.

Can confirm this appears to be a bug in the current logic. The requirement for email confirmation kicks-in and redirects the user just before groups are synced. Applies to both LDAP and SAML2 authentication & group sync. The email confirmation flow then does not re-enforce group sync itself.

Need to change the logic to either sync groups on initial user creation or as part of confirmation flow.

From my testing, the correct groups should still be assigned upon future logins. Alternatively, You may be able to achieve your setup via limiting emails based on domain using the LDAP_USER_FILTER instead of needing to use the BookStack domain restriction option. Something like this:

LDAP_USER_FILTER=(&(sAMAccountName=${user})(mail=*@example.com))

Would need to test that though, My LDAP knowledge is limited.

I'll assign this for the next feature release since it involves authentication therefore needs extra consideration and testing. Might be a small while before a feature release is ready though.


For my future reference, It's likely specifically this exception that causes the change in path before group sync:
https://github.com/BookStackApp/BookStack/blob/master/app/Auth/Access/RegistrationService.php#L82

@ssddanbrown commented on GitHub (May 2, 2020): Thanks for reporting @mikeyz24. Can confirm this appears to be a bug in the current logic. The requirement for email confirmation kicks-in and redirects the user just before groups are synced. Applies to both LDAP and SAML2 authentication & group sync. The email confirmation flow then does not re-enforce group sync itself. Need to change the logic to either sync groups on initial user creation or as part of confirmation flow. From my testing, the correct groups should still be assigned upon future logins. Alternatively, You may be able to achieve your setup via limiting emails based on domain using the `LDAP_USER_FILTER` instead of needing to use the BookStack domain restriction option. Something like this: ```bash LDAP_USER_FILTER=(&(sAMAccountName=${user})(mail=*@example.com)) ``` Would need to test that though, My LDAP knowledge is limited. I'll assign this for the next feature release since it involves authentication therefore needs extra consideration and testing. Might be a small while before a feature release is ready though. --- For my future reference, It's likely specifically this exception that causes the change in path before group sync: https://github.com/BookStackApp/BookStack/blob/master/app/Auth/Access/RegistrationService.php#L82
Author
Owner

@mikeyz24 commented on GitHub (May 2, 2020):

Thanks for the response. I just have a followup question then. If i turn off Domain restriction, for me the new user gets the default role + their AD group role. Is this by design or can I make it so that the default role is the AD group the user is a member of?

I have LDAP_REMOVE_FROM_GROUPS=true while testing

@mikeyz24 commented on GitHub (May 2, 2020): Thanks for the response. I just have a followup question then. If i turn off Domain restriction, for me the new user gets the default role + their AD group role. Is this by design or can I make it so that the default role is the AD group the user is a member of? I have LDAP_REMOVE_FROM_GROUPS=true while testing
Author
Owner

@ssddanbrown commented on GitHub (May 2, 2020):

@mikeyz24 By design. Could always set that to a group without any permissions assigned.

@ssddanbrown commented on GitHub (May 2, 2020): @mikeyz24 By design. Could always set that to a group without any permissions assigned.
Author
Owner

@ssddanbrown commented on GitHub (Aug 4, 2020):

I have updated the flow so email confirmation does not stop remaining registration actions, including group sync, to take place. Will be part of v0.30.

Thanks again for reporting @mikeyz24.

@ssddanbrown commented on GitHub (Aug 4, 2020): I have updated the flow so email confirmation does not stop remaining registration actions, including group sync, to take place. Will be part of v0.30. Thanks again for reporting @mikeyz24.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#1698