Blocking Unauthorized Access: LDAP Filters

I love BookStack. It's a simple wiki server which is easy to deploy, and I am a huge fan of how it encourages content reuse. However, it isn't a perfect solution. One of its shortcomings is that there are some gaps in its compatibility with Active Directory (AD). It has no concept of realms, so setting up AD authentication is a bit more of a manual process than it might otherwise be. That isn't to say that it is particularly difficult, but there are some extra steps and gotchas.

Let's get into the problem that I need to solve today:

The BookStack documentation has some configuration settings for AD group syncing. This is fantastic! The problem is that without some additional filtering, all users in a configured base distinguished name (base DN) will be allowed to log in. Assuming all other vendor-recommended security settings have been understood and configured, this is certainly not the scariest thing in the world.

But why let unauthorized users in at all? Maybe there was a security recommendation that you thought you understood but didn't configure correctly, allowing an authenticated but unauthorized user to view some sensitive information that could result in compromise.

You could easily argue that this is an outlier situation, but we see configuration errors and oversights all the time in the IT industry. It may not even be an error made during initial setup. The vendor could remove an option or change the option's name, and you could overlook it, or maybe you skipped a version and didn't see the changelog where the change was documented. Are we really willing to roll the dice on this? Personally, I see no reason to let someone in who I did not expressly intend to let in.

So, with all the extra context and hypothetical drama out of the way, let's look at the solution that is going to save me from this particular boogie man. This is it, a single LDAP filter applied to the configuration.

(&
  (sAMAccountName=${user})
  (memberOf=cn=BookStack_Users,cn=Users,dc=example,dc=com)
)

What this does is point to a specific AD group as a choke point. Any users not in the BookStack_Users group will be denied. That narrows things down a bit too much though. I still want to allow additional groups for different roles and permissions. To do this, I just need to add an extra string to the filter like so.

(&
  (sAMAccountName=${user})
  (memberOf:1.2.840.113556.1.4.1941:=cn=BookStack_Users,cn=Users,dc=example,dc=com)
)

The addition of :1.2.840.113556.1.4.1941: adds an extensible matching rule which will check nested group memberships. This allows me to grant access to additional groups such as BookStack_Admins, BookStack_Editors, etc, and have them all sync up with appropriately applied permissions. As long as they're in the primary group, they're covered.

You can probably tell that the additional LDAP filter is not the reason why I wrote this; it's the reasoning behind the change that prompted the article. The vendor does not have this solution documented, but it was worth it to me to make sure I kept the door locked.

As I mentioned, I am a big fan of this product! You can see my full writeup about it here.

Thanks for reading!