This post details the installation of OpenLDAP to manage users and authentication.

First configuration

Ref: (in French)

OpenLDAP is installed using the package slapd:

sudo apt install slapd
sudo dpkg-reconfigure slapd
where the answers have to be:
  • Omit OpenLDAP server configuration? No
  • DNS domain name:
  • Organization name: FunOrg
  • Create database? Yes
  • Administrator password: ***
  • Do you want the database to be removed when slapd is purged? Yes
  • Remove old database? Yes

In addition, the command slappasswd can be used to set an ecrypted administrator password. The file /etc/ldap/ldap.conf is then edited to contain the following files:

BASE	dc=mydomain,dc=org

URI	ldap://localhost:389

DEREF never

At this stage, OpenLDAP is operational and can be started with:

systemctl start slapd.service

Creating groups and users

Ref: (in French)

First, ldap-utils is installed:

sudo apt install ldap-utils
and can be used to add a new ldiff file that contains the structure of users and groups (hereafter named init_ldap.ldiff:
dn: ou=Someone,dc=mydomain,dc=org
objectClass: organizationalUnit
ou: Someone

dn: ou=AGroup,dc=mydomain,dc=org
objectClass: organizationalUnit
ou: AGroup

dn: cn=tuxette,ou=AGroup,dc=mydomain,dc=org
objectClass: posixGroup
cn: tuxette
gidNumber: 10000

dn: uid=tuxette,ou=Someone,dc=mydomain,dc=org
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: tuxette
sn: Chix
givenName: Tuxette
cn: Tuxette Chix
displayName: Tuxette Chix
uidNumber: 1000
gidNumber: 10000
gecos: Tuxette Chix
loginShell: /bin/bash
homeDirectory: /home/tuxette
shadowExpire: -1
shadowFlag: 0
shadowWarning: 7
shadowMin: 8
shadowMax: 999999
shadowLastChange: 10877
postalCode: 31000
l: Toulouse
mobile: +33 (0)X XX XX XX XX
homePhone: +33 (0)X XX XX XX XX
title: System Administrator
postalAddress: A street in Toulouse
initials: TC

This file indicates that groups are named AGroup, users are named Someone. Then, a first group tuxette and a first user tuxette are declared. The LDAP database is updated with

sudo ldapadd -x -D cn=admin,dc=mydomain,dc=org -W -f init_ldap.ldiff

Authentication with LDAP

Ref: (in French) and

The following packages are first installed:

sudo apt install libnss-ldap libpam-ldap
with the following answers:
  • LDAP URI: ldap://localhost:389
  • Distinguished name of the search base: dc=mydomain,dc=org
  • LDAP version to use: 3
  • Make local root Database admin: Yes
  • Does the LDAP database require login? No
  • LDAP account for root: cn=admin,cd=mydomain,cn=eu + password

The following step requires the edition of /etc/nsswitch.conf where ldap is added to passwd and group lines.

Then, PAM is configured with the edition of </code>/etc/pam.d/common-password</code> where use_authtok is removed from line 26:

password [success=1 user_unknown=ignore default=die] try_first_pass
and the edition of /etc/pam.d/common-session where the following line is added:
session optional skel=/etc/skel umask=077
to allow the automatic creation of the home directory at first connexion.

The proper functionning can be tested with

sudo su tuxette
that should create the home directory /home/tuxette and change the current user to tuxette.

LDAP password management


LDAP user passwords can be managed by installing ldapscripts (that is also convenient to add and remove users and more generally to manage the LDAP database):

sudo apt install ldapscripts

It is configured by editing the file /etc/ldapscripts/ldapscripts.conf so as to obtain:


To allow root to automatically use its password, use:

sudo sh -c "echo -n '***' > /etc/ldapscripts/ldapscripts.passwd"
where *** is the admin root password. This file needs to be protected with:
sudo chmod 400 /etc/ldapscripts/ldapscripts.passwd

Then, the command

ldapsetpasswd tuxette
can be used to set tuxette's password. It can be tested by an external SSH connexion (if password connexion is allowed)

Manage LDAP sudoers


To add a user to the sudoers group, first create the corresponding group (named admin) in LDAP and add tuxette to the admin group:

ldapaddgroup admin
ldapaddusertogroup tuxette admin

This should give tuxette the right to use sudo.

Install phpldapadmin


A web user interface is provided to manage the LDAP database. It is easily installed with:

sudo apt install phpldapadmin
and can be accessed at right after the installation. A virtual host can be created after commenting the redirection in /etc/apache2/conf-available/phpldapadmin.conf. The configuration file is located at /usr/share/phpldapadmin/config.php with the need to edit
$servers->setValue('server','name','LDAP on myserver');
$servers->setValue('server','base', array('dc=mydomain,dc=org'));
to require login to access your LDAP server information.

Activating memberOf overlay

Refs:,, and

To give access to certain features (typically, access to some PhP services like nextcloud), you need to have another group management besides posixGroup. This group management is included in an overlay (additional module) called **memberOf**. To activate and configure it, you'll need to edit the config part of the database (which can not be handled with phpldapadmin). First create two files: one called activation_memberof.ldif that contains

dn: cn=module,cn=config
objectclass: olcModuleList
objectclass: top
olcmodulepath: /usr/lib/ldap
and the other called configuration_memberof.ldif that contains
dn: olcOverlay=memberof,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
The module is then activated and configured using the command lines:
ldapadd -Y EXTERNAL -H ldapi:/// -f memberof_act.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f memberof_conf.ldif

At this step, **memberOf** is operational and allows you to create groups of types memberOf. These groups have a mandatory field which indicates which users are member of the group. Such a group can thus not be empty. For instance, to create a group called myappuser (intended to grant access to the service provided by myapp to certain users, members of this group), you first create a file myappuser_creation.ldif that contains

dn: cn=myappuser,ou=AGroups,dc=mydomain,dc=org
objectClass: groupOfNames
cn: myappuser
member: uid=tuxette,ou=Someone,dc=mydomain,dc=org
that you import using phpldapadmin menu or with the command line:
ldapadd -x -D cn=admin,dc=mydomain,dc=org -W -f myappuser_creation.ldif

Personal note about unresolved issue: default setting of ldapscripts (with the command lines ldapadduser and ldapaddgroup) does not allow to directly create this type of groups (or does not even create a user with inetOrgPerson), even if the configuration file /etc/ldapscripts/ldapscripts.conf is modified to include:

(this modification leads to a consistency error, stating a relation between posixGroup and memberOf. Templates for these commands are included in /usr/share/doc/ldapscripts/examples and can potentially be modified to solve this issue but this is still to be fixed for me.

The first steps of the installation of a new distribution of Ubuntu 20.04 on Kimsufi (KS7) server comprises the following steps:

Basic installation from the OVH template and upgrade to 20.04 LTS

This step is simply performed by a connexion to Kimsufi interface on which you are directly prompted that your server is available for a fresh install. Clicking on "Réinstaller", you are then asked to choose your distribution (in my case, Ubuntu server 18.04 LTS). I chose a custom installation but did not change anything (except for the hostname and for my ssh public key that I added to allow for a secure SSH connexion). Once the installation performed, the connexion is done using

ssh root@IP

Upgrade to Ubuntu server 20.04 LTS is finally performed with:

apt update
apt upgrade
do-release-upgrade -d

(the -d command is used here to allow the upgrade since 20.04 LTS was still not officially released at the time of my upgrade). During the upgrade, I systematically chose to install the new version of some configuration files and I was also notified of a message on grub not being installed that I ignored. I finally rebooted and edited the file /etc/hostname (with yet another reboot) to give the server its brand new name (with the corresponding update in the file /etc/hosts)!

Setting network time protocol (NTP)

NTP allows to synchronize dates and times through internet. The former ntpd program has been replaced by timedatectl (documentation in French at this link) that provides the same features. The main command is timedatectl that provides the current time status.

First, I switched to my timezone (Europe/Paris) by first checking the European time zones available:

timedatectl list-timezones | grep Europe
and using
timedatectl set-timezone Europe/Paris

Then, I enabled time synchronization through NTP by first editing the configuration file /etc/systemd/timesyncd.conf to add NTP servers (servers can be chosen among this list if you are located in France; otherwise, choose servers close to your location). Servers are sequentially after FallbackNTP (and this line has to be uncommented). Finally, synchronization is allowed with:

timedatectl set-ntp true
and a last check of time status gives:
> timedatectl
               Local time: Fri 2020-07-17 15:57:06 CEST
           Universal time: Fri 2020-07-17 13:57:06 UTC 
                 RTC time: Fri 2020-07-17 13:57:06     
                Time zone: Europe/Paris (CEST, +0200)  
System clock synchronized: yes                         
              NTP service: active                      
          RTC in local TZ: no

Securing SSH connexion

SSH connexion is then secured by forbidding SSH authentication with the edition of /etc/ssh_config and the addition of two lines:

ChallengeResponseAuthentication no
PasswordAuthentication no
followed by a reboot. Only ssh connexion will then be authorized. SSH public keys are stored in the user file ~/.ssh/authorized_keys (with drwx------ on .ssh and rights rw-r--r-- on the file).

I performed the upgrade from Ubuntu (server) 16.04 LTS to Ubuntu 18.04 LTS pretty late this time (on December 2019: it was about time!) and it mostly went smoothly except for a few bugs that I solved as described below:

  • no internet after upgrade: the weirdest bug was the fact that I lost most internet access from server (not to server) after the upgrade. I solved this issue as documented in this thread: I edited the file /etc/systemd/resolved.conf to add the line:
    and re-started the system with
    systemctl restart networking
  • php reconfiguration: php was not working anymore because the previous version was php5, having become obsolete. I re-installed the base php packages:
    sudo apt install php libapache2-mod-php php-mcrypt php-mysql
    and enabled the php module in apache
    a2enmod php7.2
    systemctl reload apache2
  • bug in nextcloud: I was on an old version of nextcloud, which is not upgraded by the system ugrade since it is not a distribution package. Nextcloud showed a blank pages and apache logs (/var/log/apache2/error.log for me) gave the following message:
    Local::copyFromStorage() not compatible with OC\Files\Storage\Common::copyFromStorage
    The bug was documented on nextcloud github repository and I solved it as was done by one of the developer in this commit by editing the file lib/private/Files/Storage/Local.php in nextcloud directory to add the argument $preserveMtime = false to the function copyFromStorage.

Last fresh install of the desktop version of xUbuntu 18.04 (3rd release) turned out to have a bug in the lock behavior: whenever the screen/session was supposed to lock, the computer stopped instead. The bug comes from xfce screensaver. Installing

sudo apt install xscreensaver

let xscreensaver takes the precedent over xfce screensaver and solves the issue.

Since the last update I made on xUbuntu 18.04 LTS, I got a bug with the file manager (I am using nautilus) that was refusing to open files (only directories opened).

After a few research, I found that this bug has already been identified and is related to new Xfce settings. It is solved by removing (or commenting) the line x-scheme-handler/file=exo-file-manager.desktop in the following files:

  • /usr/share/xubuntu/applications/defaults.list
  • ~/.config/mimeapps.list
  • ~/.local/share/applications/mimeapps.list