I have recently taken the opportunity to explore Wiki.js as a replacement for a MediaWiki system.
You can add authentication strategies from sources such as Auth0, Azure AD, Facebook, GitHub, Google, LDAP / Active Directory, OAuth2, Slack, and a number more. The current network has a Domain Controller with an Active Directory, so I wanted to integrate that.
The first thing that came to light was that Active Directory (AD) will talk in LDAP on port 389 and LDAPS (secure) on port 636 natively. Sounds great! However, not being an LDAP or Active Directory expert and a lack of documentation from Wiki.js, this became a challenge of “try and sees”.
We want to allow any users under the “Staff” folder, in the AD, to be able to edit the wiki.
Here is a screenshot of the default “LDAP / Active Directory” configuration in Wiki.js
Secure LDAP traffic
At first, I tried connecting to port 389, without success. After some research, it appeared that Microsoft may have disabled unencrypted LDAP traffic. It allows attackers to exploit a man-in-the-middle attack to gain elevated privileges. However, at the time of this writing 7/2022, they changed it to an explicit recommendation. It appears that port 389 would have worked, but I haven’t tested it. I ended up installing the Active Directory Certificate Services Role and Certification Authority Role Service on the domain controller. Then set up a standalone certificate authority, which issues self-signed certificates to the AD. I tested it by running “ldp”, using the run command, and connecting to the local AD on port 636 (SSL option checked). You see a bunch of output after you hit OK if it connects successfully. You probably want to go this route to secure your authentication traffic. I followed this article at IDMWORKS by Christine B.
I do not believe channel binding and LDAP signing is supported by the Wiki.JS connector at this time. So I did not explicitly enable those on the AD. I would like some feedback on this however.
This connector needs a username and password to request a match of the end-users credentials. This is a basic user who is only part of the domain users group. Look up the “distinguishedName” attribute under the “Attribute Editor” tab, in the user’s properties on the AD. Use this in the “Admin Bind DN” and populate the password assigned. The “CN”‘s are the common names, the “DC”‘s are the domain components. The entry is the hierarchy path moving from right to left.
The users we want to let in are in the “Staff” organizational unit (OU). They look like folders in the Active Directory UI. So we set the search base to look there.
“uid” is undefined by default in AD. However “sAMAccountName” is populated. So we’ll want to swap that out to use “sAMAccountName”. This is an enforced unique value on the domain.
We want Wiki.js to communicate via TLS on port 636, but not verify the certificate since it’s self-signed. We could have exported the cert and installed it on NodeJS to allow verification. However, since this is a small internal network and didn’t want to figure out renewing the cert on the Wiki server, I opted to leave verification disabled. If you don’t, you will get a “unable to verify first certificate” error.
Change the Unique ID Field Mapping to “sAMAccountName”.
Typically the email address field is not populated, however, it so happens that the “userPrincipalName” attribute matches the email pattern. So we’ll use that for the Email Field Mapping.
I turned on “Allow self-registration” since we want to allow any “Staff” to edit the wiki. You can limit the domain and assign them to a default Wiki.js group.
LDAP Search Tool
If you need help troubleshooting, consider installing ldapsearch. I used an article at https://www.agix.com.au/ldapsearch-active-directory/
apt-get install ldap-utils
yum install openldap*
ldapsearch \ -x -h ad.server.local \ -D "WikiAuthUser" \ -W \ -b "dc=ad,dc=myorg" \ -s sub "(cn=*)" cn mail sn
I hope this helps a number of folks out as it took a lot of research and guesswork to piece that all together.