mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-07 11:19:38 +03:00
LDAP Group Sync with iRedMail LDAP #2891
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @armouredking on GitHub (Jul 4, 2022).
Attempted Debugging
Searched GitHub Issues
Describe the Scenario
LDAP Sync to iRedMail does not appear to completely work with Bookstack. It is working on some level though. When I initially tried to set things up with default settings, I kept being unable to login for an unspecified error. Additionally, enabling the dump settings in the environment file did not achieve anything.
Removing the LDAP group sync part allowed me to login with an iRedMail LDAP user account, so I knew it had to be a group setting issue. Eventually determined it to be the memberOf part, the documentation seems to imply that I should be defining the attribute on the user DN which defines the groups (which for iRedMail the user attribute mapping to groups is memberOfGroup, not memberOf). This however did not work and caused the login for unspecified error issue, which was corrected by changing the attribute to "mailList" (what defines Groups for iRedMail).
With these settings (placed in logs for clear view), I was able to login, and my administrator was mapped to the LDAP user that has the Administration label. Great. The issue is no other user will map. Initially I thought it was because of the usernames having spaces, but I tried every iteration I could of hypens, underscores, capitals, etc after the initial read on the docs and none of them work. Users can login, but they have no role so they cannot see anything, and the role_user table in MySQL is likewise missing an entry for them. The users table does get updated when they login. I tried using new accounts as well, just to see if the sync only applied on initial user creation (though that doesn't seem right) and nadda.
So I turned the dump option back on, and that's when I noticed this:
parsed_direct_user_groups [ ]
parsed_recursive_user_groups [ ]
The thing is, I can see the following as well just above it in the dump:
memberofgroup:
0: "genauth@removed.removed"
count: 1
So Bookstack knows I have groups, but it does not appear to be parsing them, so maybe it can't use them? But then, how does admin work? The LDAP admin group is Administration, not admin, so it's not a 1:1 mapping despite starting the same. Based on the docs, cn=value should be what goes in the External Authentication IDs field but this does not allow for mapping for the other users. Additionally, the docs state we should be able to use the User CN as well for mapping, and this does not provide them roles either. Putting in the user CN values for the role does not allow that user to gain the role, and logging in / out does not change things for them.
Exact BookStack Version
22.06.2
Log Content
AUTH_METHOD=ldap
LDAP_SERVER=removed
LDAP_BASE_DN="o=domains,dc=removed,dc=removed"
LDAP_DN="cn=vmail,dc=removed,dc=removed"
LDAP_PASS="removed"
LDAP_USER_FILTER=(&(uid=${user})(objectClass=mailUser)(enabledService=bookstack)(accountStatus=active))
LDAP_VERSION=3
LDAP_ID_ATTRIBUTE=uid
LDAP_EMAIL_ATTRIBUTE=mail
LDAP_DISPLAY_NAME_ATTRIBUTE=cn
LDAP_THUMBNAIL_ATTRIBUTE=jpegphoto
LDAP_START_TLS=false
LDAP_USER_TO_GROUPS=true
LDAP_GROUP_ATTRIBUTE="mailList"
LDAP_REMOVE_FROM_GROUPS=false
In case it helps, this is my working LDAP configuration for Authelia (which can use TLS because I can specify my servername in the config, otherwise I'm connected locally via an IP address so it would need to turn off TLS verification but given the LDAP connection is an etherstub network with no external access non-SSL should be fine for BSA and others) using iRedMail (maybe this is a search issue, since I can't define filters for group search?):
ldap:
implementation: custom
url: ldap://removed
timeout: 5s
start_tls: true
tls:
server_name: removed
skip_verify: false
minimum_version: TLS1.2
base_dn: o=domains,dc=removed,dc=removed
username_attribute: uid
additional_users_dn: ou=Users,domainName=removed.removed
users_filter: (&({username_attribute}={input})(objectClass=mailUser)(accountStatus=active)(enabledService=authelia))
additional_groups_dn: ou=Groups,domainName=removed.removed
groups_filter: (&(member={dn})(objectClass=mailList)(accountStatus=active)(enabledService=authelia))
group_name_attribute: mailingListID
display_name_attribute: cn
permit_referrals: false
user: cn=vmail,dc=removed,dc=removed
password: removed
PHP Version
LinuxServer Docker Container
Hosting Environment
LinuxServer Docker Container
@ssddanbrown commented on GitHub (Jul 4, 2022):
Hi @armouredking,
Such error views can be debugged via the error log file mentioned on our debugging page: https://www.bookstackapp.com/docs/admin/debugging/#error-log-file
BookStack LDAP group sync will only work when provided with
memberOfstyle group data. I believe that both thememberOfGroupandmailListproperties have different structures/value-types which would make them incompatible.I would assume that no group sync is active, and this admin account was simply already assigned to the admin role.
@armouredking commented on GitHub (Jul 4, 2022):
Ah, well that'd be the first issue then. The doc files state it being missing is a permission issue, but in the LinuxServer docker it simply isn't presented to persistent storage. As such, any time the container is recreated, it is lost. Is there an ENV attribute I can set to move this to the LinuxServer logs folder on the persistent storage volume? I can map it of course via Docker, but I would prefer to keep as much configuration as possible in the ENV file. I did not see an example in the complete file.
memberOfGroup for iRedMail LDAP is in the form of an email address, which is the name of the mailList. mailList contains both
cnandmemberservice data (where member is a repeated entry matching the assigned group user'sdn). What shouldmemberOfdata look like that would make it incompatible with using an email address to match?I do not get any errors in laravel.log with LDAP_GROUP_ATTRIBUTE set to
mailList, but when set tomemberOfGroupI get the following error when attempting login:So, with
mailListit seems like some part of the data is in a form that it can understand. This is whatmailListhas for data in the table:It wasn't assigned that I can recall, as the user was created upon login, same as the others. Though it does sound like sync is not working still.
@ssddanbrown commented on GitHub (Jul 4, 2022):
The linuxserver image specific provides this log in the mounted config file, it should be at
www/laravel.logwithin the volume mounted to/config.memberOfis a list of groups that the user is a member of, referenced by the group's full DN.@armouredking commented on GitHub (Jul 4, 2022):
Well that's sort of an odd decision. I would expect it to be located at /config/log with the other log files. I guess I can deal with it being odd.
So is the issue then that memberOf is looking for every group on one line, and memberOfGroup is repeated lines with one entry per line? That seems to be the case with array/bool in the throw. Why does assigning
mailListas the group attribute not cause an error, though? Is it because BSA never actually queries / searches the groups DN, and just relies on the user DN to provide all the information?@ssddanbrown commented on GitHub (Jul 4, 2022):
I don't know the specifics of each but yeah, likely expecting on format/type of data but getting another.
It's likely that the format of this data is similar enough to that of
memberOfso now error is thrown. BookStack may do some further lookups, to get nested groups if I recall, but it may be treating the values directly as CNs, othwerwise yes, ThememberOfDNs could provide enough alone since they provide group names.@armouredking commented on GitHub (Jul 4, 2022):
Ah, so, no.
mailListis not a user parameter, it's the attribute for how groups are defined in iRedMail LDAP. I assume then that you were correct with your initial statement, no mapping is being done as no data is returned that BSA understands. Not sure how the admin got mapped then as I don't remember doing it, but meh.Example: the group object definition attribute is
mailList, with theDNbeing mail=genauth@domain.tld,ou=Groups,domainName=domain.tld,o=domains,dc=domain,dc=tld. Users are mapped to groups via thememberOfGroupattribute in the user DN and thememberattribute in the group DN, where multiple users/groups are defined as a newmemberormemberOfGroupattribute for each user/group (ie one line per, not an array).I assume it throws no errors because mailList is not an attribute type of the user DN, and BSA is not doing a group filter query. None of the information returned by the group dump is coming from the group DN
mailListassociated with any user group listed bymemberOfGroupin the dump, only the user DN attributes. So my presumption is that BSA simply finds no groups and throws no error, becausemailListis not a user attribute. Indeed, this appears to be the case, as changing LDAP_GROUP_ATTRIBUTE to the attributemakebelieveallows you to login without error as well.Here for example is a cleaned group dump:
The iRedMail LDAP does not have a defined attribute for
memberOfso I cannot manually insert it either, not without risking unintended consequences by changing the schema. Without BSA being able to readmemberOfGroup, the only two options I see is to find an unused attribute in schema to manually recreate thememberOfentry and feed that to BSA via the user attribute definition in the env file, or to give up on group sync.Should I close this, since it's support/question, and request
memberOfGroupread as a feature?@ssddanbrown commented on GitHub (Jul 4, 2022):
To be honest, my response to such a feature request would be much the same this similar issue: https://github.com/BookStackApp/BookStack/issues/2380#issuecomment-861802262
I saw that iRedMail is somewhat backed by OpenLDAP. I know I've gotten a
memberOfoverlay working before, not sure how viable that would be here.Alternatively, our logical theme system does provide access to handling certain events including login/registration. If handy with hackery, you might be able to use such events and run any required queries to emulate role sync.
@armouredking commented on GitHub (Jul 4, 2022):
iRedMail is using OpenLDAP, but its own schema system for definition. I'm not sure why
memberOfis not one of the attributes, I just know that you cannot select it from the default configuration. I can try and see if the module is included with iRedMail (I think it should be, given that they are using slapd from upstream and just adding their own schema to it) and go from there.For now, I will leave this open as "Support" in the event that I can get it working so I can add on the method for how, because I do think it is something people will run across. NextCloud configurations for iRedMail are also not "standard" but there is documentation in the iRedMail forums for getting it to work, hopefully can do something similar here for anyone else running this environment. NextCloud has a greater userbase than BSA, which is probably why it has not come up before.
@armouredking commented on GitHub (Jul 6, 2022):
Ok. So this is how to get iRedMail LDAP working with BSA:
Add moduleload memberof after the other moduleloads already in the /etc/ldap/slapd.conf file:
modulepath /usr/lib/ldap
moduleload back_mdb
moduleload back_monitor
moduleload memberof
Add the following to the very end of your /etc/ldap/slapd.conf file (I put a comment with mine, but I can't stop GitHub from turning it into a header here so just the lines):
memberof-group-oc mailList
If you have not already added users to mailing lists, do so now. They should show up with an ldapsearch for memberOf (remember, memberOf is an optional parameter so you must specify it for it to show up in ldapsearch). If your members are already assigned to mailing lists, I had to unassign them and then assign them again before the memberOf mapping occurred. It didn't just work for me, which resulted in a lot of hair pulling since it looked as if it wasn't working with just updating the slapd.conf file.
To setup the sync in BSA, you need to use the mailing list's email address as the group name for External Authentication ID. BSA's grouping for iRedMail LDAP does not appear to use the CN attribute (at least it did not work for me) for EAIDs field (which can be seen be using the LDAP_DUMP_USER_GROUPS=true option and logging in as a user, preferably one that has all the groups assigned you intend to use so you can use it as a reference for setting up the EAIDs).
I was also never able to get the user mapping working for assigning group sync (the docs group sync section says you can use account or group for this, but I attempted user CN, user DN name, and user email and could not get the user to have the desired role, even logging in and out. The instant I added the user to a group that was mapped in the EAID field and logged out/in, it worked just fine).