Network Engineering

Using OpenLDAP to Authenticate to Dokuwiki Part 2

This was a school assignment

This will be a continuation of the last report so this will look at LDAP (Lightweight Directory Access Protocol) software that will be compatible with DokuWiki. DokuWiki is not an enormously popular wiki but it does indeed have support for LDAP authentication. [1] It requires the LDAP Authentication plugin to be installed into the application. The webpage [1] has examples of many different types of LDAP servers that it can communicate with including OpenLDAP, Active Directory, TinyLDAP and Apache Directory amongst others.

As this is a Linux project Active Directory while arguably the most feature rich will not be chosen as being a Microsoft product will require more dependencies such as a Windows Server virtual machine and more complicated licensing issues. So, the focus will be on LDAP servers that can be installed for free on Ubuntu that support SSL/TLS security.

The reason OpenLDAP was chosen for this assignment was because it appeared that there was a lot more documentation available for it compared to the other options besides Active Directory which was not chosen for above reasons. OpenLDAP uses “The OpenLDAP public License” which can be found here [2].

Part 1: Installing OpenLDAP and filling with data.

This website was mostly followed. [3] On VM2 or whichever one has the Dokuwiki Webserver running.

sudo apt install slapd ldap-utils
sudo apt-get install php-ldap
sudo a2enmod authnz_ldap 
sudo systemctl restart apache2 

These commands firstly download the LDAP Server and secondly a PHP library that allows LDAP to interface with Dokuwiki/Php then restarts the apache2 application.

 sudo apt dpkg-reconfigure slapd 
  • Choose No
  • Create a domain name:
  • Organisation: example
  • Enter a password: ‘yourpassword’
  • Choose MDB
  • Choose No
  • Choose Yes
create a file add_entries.ldif
nano add_entried.ldif

Use the content of the one demonstrated on this website which is what this solution used [3].
In this file add the data from the Ubuntu website or edit your own from workshop 2.

Now access the Dokuwiki website if unchanged from last time will be on

Login at the top right use the account created from the last report Go to Admin Panel extension manager Enable LDAP Auth Plugin Click Admin again this time go to Configuration Manager
Under the Authentication Section change authtype to ‘authldap’ Go to the Authldap section

Figure 1: Admin settings configuration panel.

If you are using the LDAP example from the website the settings in the figure above will work otherwise configure them to do this the hostname and port should be the same on either configuration. After filling the form out click save. The main issues here to take away is that the third and fourth option need to be able to find the OU that contain the users and groups.

This will now lock you out of your admin account as it doesn’t now allow local accounts but only LDAP accounts. You will now be able to log on using one of your LDAP accounts.

There are still a few settings that need to be configured these can be done from. /var/www/dokuwiki/dokuwiki-2018-04-22b/conf There are still a few settings that need to be configured these can be done from.


This website here [4] shows different possible configurations for making LDAP work with DokuWiki. This is the working configuration in Figure 2. All the above configurations from Figure 1 can also be done here or changed if needed.

This website here [4] shows different possible configurations for making LDAP work with DokuWiki. This is the working configuration in Figure 2. All the above configurations from Figure 1 can also be done here or changed if needed.

Figure 2: /var/www/dokuwiki/dokuwiki-2018-04-22b/conf/local.php

To fix the admin account problem [5] in the $conf[‘superuser’] = ‘’; you can enter an LDAP user of your choice or a superuser group by using the @symbol separated by commas.

Part 2: Configuring SSL/TLS LDAP

sudo apt-get install tcpdump tcpdump -w file_name.pcap -i {interface-name}

By using this command it will record all traffic on the specified adapter interface and save it to a file I chose the loopback address as the traffic was moving on the same VM. I logged in and out a few times on the wiki and then turned it off. Searching for the password gave us 16 matches.

Figure 3: Unencrypted Loopback traffic showing ldap/website authentication password.

This is not to concerning because if the website was in actual use the loopback address would not be tcpdumped from the outside unless someone broke into the system at which point, they would have access anyway.

Figure 4: Websites unencrypted HTTP traffic over Network

With the client accessing over the network we can see that it contains loads of unencrypted traffic including the password token which is not good as anyone on the network could snoop this connection.

This website [6] was used to understand how to add HTTPS to a website. This is necessary to encrypt the above information in figures 3 and 4 to make it more difficult for attackers to steal login credentials. All the default options were followed from [6] besides the Firewall section which was left out as it was not necessary.

Figure 5: HTTPS Enabled Wiki.

Final Configuration settings shown below.

Figure 6: Dokuwiki.conf file in apache.
Figure 7: apache ports file
Figure 8: 000-default apache file. This will redirect http to https disable unencrypted access.
Figure 9: After Enabling HTTPS on the website traffic searches for the user and password no longer visible.

In Figure 9 It is shown that unlike the previous tcpdumps now that the website in running HTTPS there are 0 results for the user account or the password at the least protecting an attacker from readily reading the traffic.


[1] “LDAP Authentication Plugin,” [Online]. Available: [Accessed 12 6 2019].
[2] “Public License for 2.4.47,” [Online]. Available: [Accessed 17 6 2019].
[3] “OpenLDAP Server,” Ubuntu, [Online]. Available: [Accessed 16 6 2019].
[4] “Open:Ldap,” [Online]. Available: [Accessed 15 6 2019].
[5] “SuperUser,” [Online]. Available: [Accessed 15 6 2019].
[6] “How To Create a Self-Signed SSL Certificate for Apache in Ubuntu 16.04,” [Online]. Available: [Accessed 17 6 2019].
[7] “Setting up OpenLDAP Server in Ubuntu 18.04 LTS,” [Online]. Available: [Accessed 13 6 2019].

Network Engineering

Create A DokuWiki Installation On Ubuntu 18.04 Part 1

Example of finished network.

As it is a virtualized network it is a bit more complicated but essentially the host computer or the client will interface with only the NGINX VM. NGINX then sends the request on to the backend Apache server to serve the DokuWiki installation but as far as the client/host is concerned it is only accessing the NGINX server.

Installation steps.

Instructions were found here [16] but have been verified and slightly changed with errors/overlooked steps found in the original instructions.
The current version of Ubuntu was used 18.04 that had all the updates as of 18/4/2019 Installed. This will also require 2 VM’s and the host computer all connected using a VirtualBox Host only adapter and a bridged adapter to allow the VM’s to install software.

sudo apt-get install apache2 This command installs the apache2 webserver.

To Install PHP7 and the modules for apache. This was one of the steps in the documentation that didn’t seem to work as described but these commands worked.

sudo apt-get install php libapache2-mod-php

This should have installed all the dependencies needed for DokuWiki now we will begin the installation of DokuWiki.
Create the directories for the program.
sudo mkdir -p /var/www/dokuwiki
cd /var/www/dokuwiki

Wget is a command that downloads the program from the website via the terminal.
sudo wget

Next thing we must unpack the file.
sudo tar xvf dokuwiki-stable.tgz
Change the file permissions of the folder.

chmod -R 707 /var/www/dokuwiki
NOTE: The full file structure should be this – /var/www/dokuwiki/dokuwiki-2018-04-22b If it is different to this it will need to be specified in the VirtualHost section on the directory path so that Apache can find the application.

Configure Apache for DokuWiki.

sudo touch /etc/apache2/sites-available/dokuwiki.conf

sudo ln -s /etc/apache2/sites-available/dokuwiki.conf /etc/apache2/sitesenabled/dokuwiki.conf

NOTE: This creates the dokuwiki.conf file in the sites-available folder and then creates an identically linked file in the enabled folder. Only the files in the enabled folder will be hosted by Apache but the sites-available is used for a sort of backup.
sudo nano /etc/apache2/sites-available/dokuwiki.conf
Next the dokuwiki.conf file needs to be edited.

File permissions may need to be added to the .conf files.


As mentioned previously the root of your Dokuwiki installation should be put in Document Root and may be different.

Next step is to restart the apache service. 

systemctl restart apache2.service

If this command doesn’t work you have done something wrong probably in the conf file.

systemctl status apache2 may help.
Now navigate to the hosts file. cd /etc/hosts use nano to edit the file  sudo etc nano

Add like shown in the picture below.

These need to be added so the computer knows where to find these host names this gets messy later with the reverse proxy because we don’t have a DNS server so will be easier to just stick with IP addresses.

Navigate in your web browser to your new site which will be  or the IP address but make sure to access /install.php. After the website can be accessed without install.php. Enter the installation details.

You will now have a working DokuWiki install!

Implement NGINX Reverse Proxy

This is where things start to get a bit confusing. Open a new Ubuntu Virtual machine. Make sure it is using a host only adapter and is on the same network as the host computer and the Apache server. In my case this happened to be. • Host Computer: • Apache Server VM: • NGINX Reverse-Proxy VM:  
Most of the Instructions for the reverse proxy were taken from here. [17]
Network Engineering, I give permission for this assignment to be shared NETENG ASSIGNMENT 1


Sudo apt-get install nginx
This should create all the basic directory structures to keep things simple we will just use the default files. Nginx is installed into /etc/nginx

cd /etc/nginx/sites-available
Now edit the default file i.e. nano /etc/nginx/sites-available/default and uncomment everything (#).  

At the bottom of the file add.

server {
    listen 80;
     location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

This creates a very basic proxy configuration. Server name is slightly redundant as we won’t be using DNS names because we don’t have a DNS server however if you added DNS names in the hosts file for every computer it may work. Instead use the Ip address OF YOUR APACHE WEBSERVER.

Change back to your Apache VM
Some of the settings entered earlier will need to be changed to allow it to interact with the proxy server.

Edit the /etc/apache2/sites-available/dokuwiki.conf file from before.

Change <VirtualHost> To <VirtualHost *:8080>

This will make Apache listen to any request on port 8080 which our reverse-proxy will send to Apache. This is quite a simple reverse proxy.

The file /etc/apache2/ports.conf Needs to be edited
Network Engineering, I give permission for this assignment to be shared NETENG ASSIGNMENT 1


Change the Listen section to Listen *:8080

Reload Apache systemctl restart apache2 Reload NGINX systemctl restart nginx
Verify that Apache is listening on port 8080.

sudo netstat -tlpn

If everything is correct from your host computer enter the IP address of your NGINX server not your Apache server. Ie you should receive the Dokuwiki page even though you used the IP address of your NGINX server. This is how a reverse proxy works. You could then add more servers and have them all accessed on your NGINX IP address.  

Host accessing the NGINX IP and receiving the webpage from Apache.

Future Considerations/Conclusion The dokuwiki configuration went well. Maybe some sort of DNS server could be implemented in the future to allow the hostnames to work properly with the reverse proxy. The host computer can also access the wiki directly which is not really the point of a reverseproxy, but this could be due to the Virtual networking but could also be fixed with simple firewall rules.