LDAP client

LDAP client

Especially for Ubuntu/Debian Client

En client il faut configurer LDAP pour pouvoir obtenir une authentification.

Ici je présenterai la méthode qui fonctionne sur notre réseau elle est un résumé du lien suivant: Pour l'aide générale: https://help.ubuntu.com/community/LDAPClientAuthentication

Installation des modules nécessaires à l’authentification LDAP

sudo apt-get install ldap-auth-client nscd

Aux questions sur l'intranet esoa.prive avec le serveur TerraNova

LDAP Server adresse IP : 192.168.0.2 définition du domaine LDAP : dc=esoa, dc=prive Version du LDAP = \3 Non pas de gestion par le root local des mots de passe LDAP (Mais à réfléchir pour le cas particulier des portables itinérants) non pas d'authentification pour accéder aux données LDAP

L'annuaire LDAP de l'u-psud Vous avez la possibilité d'accéder à l'annuaire depuis votre logiciel de messagerie. De cette façon, vous aurez un carnet d'adresse complet et votre logiciel pourra effectuer l'auto-complétion d'adresse lorsque vous rédigerez un message.

Pour cela, il vous faut configurer l'annuaire ldap. [C'est la config à utiliser pour les machines du C2N]

serveur LDAP : ldap.u-psud.fr
numéro du port : 389
nom distinct de base (ou base de recherche) : ou=people,dc=u-psud,dc=fr
profondeur de la recherche : un niveau
filtre de recherche : (objectclass=*) (pour Thunderbird ou Outlook), (cn=*^0*) (pour Eudora)

LDAP accès externe (exemple pour la curiosité inutile pour les machines du C2N)

serveur LDAPS (sécurisé) : ldaps.u-psud.fr
numéro du port : 636
nom distinct de base (ou base de recherche) : ou=people,dc=u-psud,dc=fr
utilisateur de connexion : uid=prenom.nom*,ou=people,dc=u-psud,dc=fr
profondeur de la recherche : un niveau
filtre de recherche : (objectclass=*) (pour Thunderbird ou Outlook), (cn=*^0*) (pour Eudora)

* : remplacez prenom.nom par votre identifiant. Votre mot de passe vous sera demandé.

Configuration du fichier /etc/nsswitch.conf pour utiliser LDAP

sudo auth-client-config -t nss -p lac_ldap

Définition des groupes locaux en plus des groupes LDAP aux utilisateurs LDAP

Modifier le fichier /etc/security/group.conf en ajoutant avant le end of file le code suivant:

#
# Config des groupes pour LDAP
#

*;*;*;Al0000-2400;audio,cdrom,dip,plugdev

Il faut bien sûr ajouter tous les groupes nécessaire au travail/jeu des utilisateurs LDAP sur le poste local (utilisation desports USB, du son et de la video)

Creation automatique des répertoires home/LDAP_user

Pour cela il faut utiliser le fichier de config my_mkhomedir que l'on copie dans /usr/share/pam-configs

Name: activate mkhomedir
Default: yes
Priority: 900
Session-Type: Additional
Session :
        required    pam_mkhomedir.so umask=0077 skel=/etc/skel

Assigner les groupes locaux aux LDAP_Users

Créer le fichier my_groups et le copier dans /usr/share/pam-configs

Name: activate /etc/security/group.conf
Default: yes
Priority: 900
Auth-Type: Primary
Auth:    required    pam_group.so use_first_pass

Finaliser

Just to make sure everything works, run the following:

sudo pam-auth-update
sudo /etc/init.d/nscd restart

Comment changer la configuration de l'authentification

Pour changer la méthode le logiciel pam-auth-update offre la configuration des options

sudo pam-auth-update

\\  === Comment configurer les paramètres LDAP  ===

: /etc/ldap.conf Pour bien configurer tous les paramètres de LDAP : https://linux.die.net/man/5/nss_ldap Il y a deux paramètres à regarder particulièrement: * nss_override_attribute_value <attribute> <value> : Specifies a value to use for the specified attribute in preference to that contained in the actual entry. This option may be specified multiple times, for different attributes. If nss_ldap was built without schema mapping support, then this option is ignored.

nss_map_attribute <from_attribute> <to_attribute> : This option may be specified multiple times, and directs nss_ldap to use the attribute to_attribute instead of the RFC 2307 attribute from_attribute in all lookups. If nss_ldap was built without schema mapping support, then this option is ignored.

Il y a d'autres options intéressantes mais ces options permettent de changer des valeurs qui pourraient être erronées dans le LDAP utilisé (ou qui créent des conflits avec la configuration locale)

\\  Exemple pour le cas de ''http://ldap.u-psud.fr''  \\  ''

''

LDAP request

To perform LDAP operation you need to install the LDAP tools

sudo apt-get install ldap-utils

Then you can perform to following operations

ldapadd      ldapdelete   ldapmodify   ldappasswd   ldapurl
ldapcompare  ldapexop     ldapmodrdn   ldapsearch   ldapwhoami

To get informations you can use ldapsearch for example:

ldapsearch -x -H ldap://ldap.u-psud.fr:389 -b "ou=people,dc=u-psud,dc=fr" "(uid=stephane.guilet)"

To get information with many criteria

ldapsearch -x -H ldap://ldap.u-psud.fr:389 -b "ou=people,dc=u-psud,dc=fr" "(&(homeDirectory=/dev/null)(departmentNumber=9022))"

\\  ===== Multiple User installation using LDAP from u-psud =====

To install the LDAP client use the followin page of the wiki:http://clearwiki.c2n.u-psud.fr/doku.php?id=ldapclient

\\    \\  But the data from the LDAP is wrong for homeDirectory attribute. The default value is ''/dev/null''.

So you have to use a hack of the pam system for the module pam_mkhomedir.so

\\  explanation in details:
\\  session    required     pam_mkhomedir.so  skel=/etc/ftp/ umask=0022

As you can see, pam_mkhomedir.so acts at the session level. This means that it acts after the user has been authenticated (by the auth facility). To do so, it defines the following PAM-specific function :

PAM_EXTERN
int pam_sm_open_session(pam_handle_t * pamh, int flags,
                        int argc, const char **argv);

As I said, this function is called when the user has been authenticated. Therefore, when it retrieves the PAM user handle…

/* Determine the user name so we can get the home directory */
retval = pam_get_item(pamh, PAM_USER, (const void **)&user);

… it gets access to the name of an authenticated, existing user. With this information, the module will be able to retrieve what it needs (the path to a home directory) through a simple getpwnam(3) library call:

/* Get the password entry */
pwd = getpwnam(user);

This will return the following structure, filled with information about the user:

struct passwd {
    char   *pw_name;       /* username */
    char   *pw_passwd;     /* user password */
    uid_t   pw_uid;        /* user ID */
    gid_t   pw_gid;        /* group ID */
    char   *pw_gecos;      /* user information */
    char   *pw_dir;        /* home directory */
    char   *pw_shell;      /* shell program */
};

Now, if you wonder where this information is coming from, have a look at /etc/nsswitch.conf. The Name Service Switch (NSS) is here to provide information regarding names in general (which can be usernames, aliases, groups, hosts, … see nsswitch.conf(5) for more details). If the guide you followed is complete enough, it should have had you configure both PAM and NSS: the first handles authentication and account/session management, while the other is merely here to provide name information. In other words, the first one can perform read/write operations, while the second one is read-only.

Once pam_mkhomedir.so has retrieved the path to the user's home directory, all it has to do is check whether or not it exists, and create it if it does not:

/* Stat the home directory, if something exists then we
 * assume it is correct and return a success. */
if(stat(pwd->pw_dir, &st) == 0) return PAM_SUCCESS;

return create_homedir(..., pwd, ...);

The create_homedir function is defined by the module itself, and it is a bit too long for me to paste it here. Just see it as a big mkdir(2) call, which handles specific cases and makes sure everything goes smoothly. If you're interested in more details, have a look at pam_mkhomedir.so's source code. I used this version of it for my answer (it was written by Jason Gunthorpe, whose name is also on my pam_mkhomedir.so manpage).

Now, as far as I'm concerned, I think the guide you followed is a little incomplete, or at least, the MySQL table it has you create is:

Field	Type	Null	Key	Default	Extra
id	int(11)	NO	PRI	NULL	auto_increment
username	varchar(30)	NO	UNI	NULL
pass	varchar(50)	NO		NULL

This table is probably detailed enough for VSFTPd to work. Since it is configured with a home root, it can easily determine a user's home directory: $ftp_root/username. This is actually set with the local_root parameter:

local_root=/home/vsftpd/$USER

However, pam_mkhomedir.so is not VSFTPd. It doesn't use this mechanism, but relies on NSS (through getpwnam(3)). The problem is: your MySQL table does not provide enough information for NSS to fill the struct passwd we saw earlier. In order to have NSS use MySQL as a source, you'll need to install nss-mysql, which requires a larger MySQL table. This will require adjustments in your VSFTPd configuration, but you should have no problem in having VSFTPd and nss-mysql cohabitate.

This directory gives an example for a minimal nss-mysql setup. The MySQL table for users is defined as follows:

Field	Type	Null	Key	Default	Extra
id	int(11)	NO	PRI	NULL	auto_increment

It took more than 10 years for OpenLDAP 2.5.x to be released, and as such it is important to understand the changes that can impact production environments and how to deal with them.

The most important change in this release is the removal of the following backends:

  BDB
  HDB
  Shell

Installations using these backends will need to migrate to a supported backend instead, like LMDB (preferred).

The nssov overlay has also been dropped from the package.

There are also a few additions:

  The new slapd-asyncmeta(5) backend.
  New core overlays: slapd-homedir(5), slapd-otp(5) and
  slapd-remoteauth(5).

At the time of this writing, you can find the upstream announcement containing the full list of changes in the 2.5.x series at https://www.openldap.org/software/release/announce.html 49. Migrating your configuration to OpenLDAP 2.5.x

The package upgrade process (using maintainer scripts) exports your databases to LDIF format using slapcat(8), then updates the slapd package, and finally imports the LDIF files using slapadd(8). If the slapadd process fails, it must be completed manually after resolving whatever issues caused by the failure.

Generally, these issues will likely be related to the use of old backends or overlays that have been removed in the 2.5.x series. For example, you can encounter problems if you are still deploying OpenLDAP using a BDB or an HDB backend. In this case, the upgrade process will not be able to automatically migrate the existing backend to LMDB, and you will have to manually intervene.

In this document we present the most common failure scenario and how to fix the problem. Bear in mind that there might be more complex cases which are not covered here and that will likely require more actions to be resolved.

For testing purposes, we are using an LXD container configured with OpenLDAP 2.4.x and deployed with a BDB backend. This container has been upgraded all the way up to Ubuntu Impish, which ships with OpenLDAP 2.5.x, but the OpenLDAP packages were held back. Let’s now upgrade them:

# apt-get update … # apt-get upgrade … Setting up slapd (2.5.6+dfsg-1~exp1ubuntu1) … Installing new version of config file /etc/ldap/schema/core.ldif … Installing new version of config file /etc/ldap/schema/core.schema … Installing new version of config file /etc/ldap/schema/cosine.ldif … Installing new version of config file /etc/ldap/schema/cosine.schema … Installing new version of config file /etc/ldap/schema/dyngroup.ldif … Installing new version of config file /etc/ldap/schema/dyngroup.schema … Installing new version of config file /etc/ldap/schema/pmi.ldif … Installing new version of config file /etc/ldap/schema/pmi.schema …

Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.57+dfsg-2ubuntu1... done.
Moving old database directories to /var/backups:
- directory dc=example,dc=com... done.
Loading from /var/backups/slapd-2.4.57+dfsg-2ubuntu1: 
- directory dc=example,dc=com... failed.

Loading the database from the LDIF dump failed with the following error while running slapadd:

  lt_dlopenext failed: (back_bdb) file not found
  config error processing cn=module{0},cn=config: <olcModuleLoad> handler exited with 1
  slapadd: bad configuration directory!

Removing obsolete conffile /etc/ldap/schema/ppolicy.schema … Removing obsolete conffile /etc/ldap/schema/ppolicy.ldif … Job for slapd.service failed because the control process exited with error code. See “systemctl status slapd.service” and “journalctl -xeu slapd.service” for details. invoke-rc.d: initscript slapd, action “start” failed. × slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)

   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /usr/lib/systemd/system/slapd.service.d
           └─slapd-remain-after-exit.conf
           /run/systemd/system/service.d
           └─zzz-lxc-service.conf
   Active: failed (Result: exit-code) since Wed 2021-08-18 17:42:39 UTC; 6ms ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1713 ExecStart=/etc/init.d/slapd start (code=exited, status=1/FAILURE)

Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: lt_dlopenext failed: (back_bdb) file not found Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: config error processing cn=module{0},cn=config: <olcModuleLoad> handler exited with 1 Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: DIGEST-MD5 common mech free Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: DIGEST-MD5 common mech free Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: slapd stopped. Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: connections_destroy: nothing to destroy. Aug 18 17:42:39 openldap-test-db-migration slapd[1713]: …fail! Aug 18 17:42:39 openldap-test-db-migration systemd[1]: slapd.service: Control process exited, code=exited, status=1/FAILURE Aug 18 17:42:39 openldap-test-db-migration systemd[1]: slapd.service: Failed with result 'exit-code'. Aug 18 17:42:39 openldap-test-db-migration systemd[1]: Failed to start LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol). …

As you can see, the upgrade process has failed. You should also have seen a debconf warning saying:

Error while performing post-installation tasks

There has been one or more errors while performing some post-installation tasks. This probably means that the slapd package could not automatically migrate one or more LDAP databases, or that a backend being used by the current OpenLDAP installation is not supported anymore.

The maintainer script responsible for executing the post-installation tasks has exited, but the slapd service has NOT been (re)started. You will need to manually fix the problem and then start the service.

For more information on possible problematic scenarios and how to address them, please take a look at the README.Debian file (under /usr/share/doc/slapd/).

This means that the slapd service has not been properly restarted and will require manual intervention (as explained above), but in order to prevent upgrade breakages the apt-get upgrade command has finished with a successful code anyway.

We now need to proceed with the manual steps required to convert our OpenLDAP installation from BDB to the LMDB backend. Let’s assume that your configuration database is stored in the default location (/etc/ldap/slapd.d).

  You need to locate the backup LDIF file exported during the upgrade
  process. This is the configuration file used by your
  installation. It should be located at:

  /var/backups/slapd-<OLDVERSION>/cn=config.ldif

  <OLDVERSION> should most likely be the latest 2.4.x version you
  had installed before attempting to upgrade to 2.5.x. In our
  example, our file is named
  /var/backups/slapd-2.4.57+dfsg-2ubuntu1/cn=config.ldif.

  Let’s make a copy of the file for working on.

  # mkdir /tmp/openldap-migration
  # cp /var/backups/slapd-2.4.57+dfsg-2ubuntu1/cn=config.ldif /tmp/openldap-migration

  Edit your copy of the cn=config.ldif file to fix the issues noted
  by slapdadd, such as removed or renamed modules or backends.
  In our case, here is what we should do:
      Change olcModuleLoad: back_bdb or back_hdb to back_mdb.
      If you have an olcBackend: bdb or hdb entry, change it to mdb, or
      delete it if you don’t have to override any global LMDB settings.
      For each configured BDB or HDB database:
      Change objectClass: olcBdbConfig or olcHdbConfig to
      olcMdbConfig. Also update structuralObjectClass.
      Change olcDatabase: bdb or hdb to mdb. Also update the
      attribute in the DN, for example:
      olcDatabase={1}mdb,cn=config.
      Delete any olcDbConfig attributes.
      Add the olcDbMaxSize attribute to set the maximum size of the
      database, in bytes. If not configured, the default is 10 MiB.

  To illustrate the changes that are necessary here, here is a diff
  from the original vs. the modified files in the example scenario
  we’re considering in this guide:

– /var/backups/slapd-2.4.57+dfsg-2ubuntu1/cn=config.ldif 2021-08-18 17:42:11.350169777 +0000

+++ /tmp/openldap-migration/cn=config.ldif 2021-08-18 18:18:20.724858076 +0000

  @@ -17,7 +17,7 @@
   objectClass: olcModuleList
   cn: module{0}
   olcModulePath: /usr/lib/ldap
  -olcModuleLoad: {0}back_bdb
  +olcModuleLoad: {0}back_mdb
   structuralObjectClass: olcModuleList
   entryUUID: 216f3358-632c-103b-8f5c-159102fdad19
   creatorsName: cn=config
  @@ -617,9 +617,9 @@
   modifiersName: cn=config
   modifyTimestamp: 20210616202109Z
   
  -dn: olcBackend={0}bdb,cn=config
  +dn: olcBackend={0}mdb,cn=config
   objectClass: olcBackendConfig
  -olcBackend: {0}bdb
  +olcBackend: {0}mdb
   structuralObjectClass: olcBackendConfig
   entryUUID: 216fb710-632c-103b-8f5d-159102fdad19
   creatorsName: cn=config
  @@ -658,10 +658,10 @@
   modifiersName: cn=config
   modifyTimestamp: 20210616202109Z
   
  -dn: olcDatabase={1}bdb,cn=config
  +dn: olcDatabase={1}mdb,cn=config
   objectClass: olcDatabaseConfig
  -objectClass: olcBdbConfig
  -olcDatabase: {1}bdb
  +objectClass: olcMdbConfig
  +olcDatabase: {1}mdb
   olcDbDirectory: /var/lib/ldap
   olcSuffix: dc=example,dc=com
   olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * non
  @@ -672,15 +672,11 @@
   olcRootDN: cn=admin,dc=example,dc=com
   olcRootPW:: *****************************************************
   olcDbCheckpoint: 512 30
  -olcDbConfig: {0}set_cachesize 0 2097152 0
  -olcDbConfig: {1}set_lk_max_objects 1500
  -olcDbConfig: {2}set_lk_max_locks 1500
  -olcDbConfig: {3}set_lk_max_lockers 1500
   olcDbIndex: objectClass eq
   olcDbIndex: cn,uid eq
   olcDbIndex: uidNumber,gidNumber eq
   olcDbIndex: member,memberUid eq
  -structuralObjectClass: olcBdbConfig
  +structuralObjectClass: olcMdbConfig
   entryUUID: 216fc25a-632c-103b-8f5e-159102fdad19
   creatorsName: cn=config
   createTimestamp: 20210616202109Z

  Move away or delete the contents of /etc/ldap/slapd.d/ so that it
  is an empty directory.

  # mkdir /tmp/openldap-migration/old-etc-slapd
  # mv /etc/ldap/slapd.d/* /tmp/openldap-migration/old-etc-slapd

  Load your edited cn=config.ldif file into the cn=config
  database:

  # slapadd -F /etc/ldap/slapd.d -n0 -l /tmp/openldap-migration/cn=config.ldif

  If the command above has failed, go back to step 2.

  After the slapadd command succeeds, change the permissions on the
  /etc/ldap/slapd.d/ directory to be owned by the openldap user:

  # chown -R openldap:openldap /etc/ldap/slapd.d/

  The file permissions should be correct, but you may want to double
  check that regular files have 0600 (-rw-------) permissions,
  and directories have 0750 (drwxr-x---) permissions.

Now you can proceed with reloading the remaining databases. Migrating your databases to OpenLDAP 2.5.x

For each configured database, you should:

  Locate the backup LDIF file exported by the upgrade process. This
  file will probably be named like:

  /var/backups/slapd-<OLDVERSION>/<SUFFIX>.ldif

  where <SUFFIX> is the database suffix, such as
  dc=example,dc=com, and <OLDVERSION> is the same version as the
  one you used to adjust the configuration file (step 1 of the
  previous section). In our case, the file is named:

  /var/backups/slapd-2.4.57+dfsg-2ubuntu1/dc=example,dc=com.ldif

  Ensure the directory where the database is stored (for example,
  /var/lib/ldap/) is empty. By default, the upgrade process moves
  away the database files to a directory named
  /var/backups/<SUFFIX>-<OLDVERSION>.ldapdb, so you should not see
  any files under /var/lib/ldap/. If you do, just move them away.

  Reload the data using slapadd:

  # slapadd -l /var/backups/slapd-2.4.57+dfsg-2ubuntu1/dc=example,dc=com.ldif

  Make sure the slapadd command succeeded, and then change the
  permissions on the data directory:

  # chown -R openldap:openldap /var/lib/ldap

After all of your databases have been reloaded successfully, you should be able to start the slapd service again:

# service slapd start # service slapd status ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)

   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /usr/lib/systemd/system/slapd.service.d
           └─slapd-remain-after-exit.conf
           /run/systemd/system/service.d
           └─zzz-lxc-service.conf
   Active: active (running) since Wed 2021-08-18 18:19:57 UTC; 2s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1960 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)Changes to OpenLDAP 2.5.x

It took more than 10 years for OpenLDAP 2.5.x to be released, and as such it is important to understand the changes that can impact production environments and how to deal with them.

The most important change in this release is the removal of the following backends:

  BDB
  HDB
  Shell

Installations using these backends will need to migrate to a supported backend instead, like LMDB (preferred).

The nssov overlay has also been dropped from the package.

There are also a few additions:

  The new slapd-asyncmeta(5) backend.
  New core overlays: slapd-homedir(5), slapd-otp(5) and
  slapd-remoteauth(5).

Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.57+dfsg-2ubuntu1... done.
Moving old database directories to /var/backups:
- directory dc=example,dc=com... done.
Loading from /var/backups/slapd-2.4.57+dfsg-2ubuntu1: 
- directory dc=example,dc=com... failed.

Loading the database from the LDIF dump failed with the following error while running slapadd:

  lt_dlopenext failed: (back_bdb) file not found
  config error processing cn=module{0},cn=config: <olcModuleLoad> handler exited with 1
  slapadd: bad configuration directory!

   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /usr/lib/systemd/system/slapd.service.d
           └─slapd-remain-after-exit.conf
           /run/systemd/system/service.d
           └─zzz-lxc-service.conf
   Active: failed (Result: exit-code) since Wed 2021-08-18 17:42:39 UTC; 6ms ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1713 ExecStart=/etc/init.d/slapd start (code=exited, status=1/FAILURE)

As you can see, the upgrade process has failed. You should also have seen a debconf warning saying:

Error while performing post-installation tasks

For more information on possible problematic scenarios and how to address them, please take a look at the README.Debian file (under /usr/share/doc/slapd/).

  You need to locate the backup LDIF file exported during the upgrade
  process. This is the configuration file used by your
  installation. It should be located at:

  /var/backups/slapd-<OLDVERSION>/cn=config.ldif

  <OLDVERSION> should most likely be the latest 2.4.x version you
  had installed before attempting to upgrade to 2.5.x. In our
  example, our file is named
  /var/backups/slapd-2.4.57+dfsg-2ubuntu1/cn=config.ldif.

  Let’s make a copy of the file for working on.

  # mkdir /tmp/openldap-migration
  # cp /var/backups/slapd-2.4.57+dfsg-2ubuntu1/cn=config.ldif /tmp/openldap-migration

  Edit your copy of the cn=config.ldif file to fix the issues noted
  by slapdadd, such as removed or renamed modules or backends.
  In our case, here is what we should do:
      Change olcModuleLoad: back_bdb or back_hdb to back_mdb.
      If you have an olcBackend: bdb or hdb entry, change it to mdb, or
      delete it if you don’t have to override any global LMDB settings.
      For each configured BDB or HDB database:
      Change objectClass: olcBdbConfig or olcHdbConfig to
      olcMdbConfig. Also update structuralObjectClass.
      Change olcDatabase: bdb or hdb to mdb. Also update the
      attribute in the DN, for example:
      olcDatabase={1}mdb,cn=config.
      Delete any olcDbConfig attributes.
      Add the olcDbMaxSize attribute to set the maximum size of the
      database, in bytes. If not configured, the default is 10 MiB.

  To illustrate the changes that are necessary here, here is a diff
  from the original vs. the modified files in the example scenario
  we’re considering in this guide:

– /var/backups/slapd-2.4.57+dfsg-2ubuntu1/cn=config.ldif 2021-08-18 17:42:11.350169777 +0000

+++ /tmp/openldap-migration/cn=config.ldif 2021-08-18 18:18:20.724858076 +0000

  @@ -17,7 +17,7 @@
   objectClass: olcModuleList
   cn: module{0}
   olcModulePath: /usr/lib/ldap
  -olcModuleLoad: {0}back_bdb
  +olcModuleLoad: {0}back_mdb
   structuralObjectClass: olcModuleList
   entryUUID: 216f3358-632c-103b-8f5c-159102fdad19
   creatorsName: cn=config
  @@ -617,9 +617,9 @@
   modifiersName: cn=config
   modifyTimestamp: 20210616202109Z
   
  -dn: olcBackend={0}bdb,cn=config
  +dn: olcBackend={0}mdb,cn=config
   objectClass: olcBackendConfig
  -olcBackend: {0}bdb
  +olcBackend: {0}mdb
   structuralObjectClass: olcBackendConfig
   entryUUID: 216fb710-632c-103b-8f5d-159102fdad19
   creatorsName: cn=config
  @@ -658,10 +658,10 @@
   modifiersName: cn=config
   modifyTimestamp: 20210616202109Z
   
  -dn: olcDatabase={1}bdb,cn=config
  +dn: olcDatabase={1}mdb,cn=config
   objectClass: olcDatabaseConfig
  -objectClass: olcBdbConfig
  -olcDatabase: {1}bdb
  +objectClass: olcMdbConfig
  +olcDatabase: {1}mdb
   olcDbDirectory: /var/lib/ldap
   olcSuffix: dc=example,dc=com
   olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * non
  @@ -672,15 +672,11 @@
   olcRootDN: cn=admin,dc=example,dc=com
   olcRootPW:: e1NTSEF9UDFDMlA1ZDhxbzZuTWR0c0p3NU50c3BBLzJBSm54T0s=
   olcDbCheckpoint: 512 30
  -olcDbConfig: {0}set_cachesize 0 2097152 0
  -olcDbConfig: {1}set_lk_max_objects 1500
  -olcDbConfig: {2}set_lk_max_locks 1500
  -olcDbConfig: {3}set_lk_max_lockers 1500
   olcDbIndex: objectClass eq
   olcDbIndex: cn,uid eq
   olcDbIndex: uidNumber,gidNumber eq
   olcDbIndex: member,memberUid eq
  -structuralObjectClass: olcBdbConfig
  +structuralObjectClass: olcMdbConfig
   entryUUID: 216fc25a-632c-103b-8f5e-159102fdad19
   creatorsName: cn=config
   createTimestamp: 20210616202109Z

  Move away or delete the contents of /etc/ldap/slapd.d/ so that it
  is an empty directory.

  # mkdir /tmp/openldap-migration/old-etc-slapd
  # mv /etc/ldap/slapd.d/* /tmp/openldap-migration/old-etc-slapd

  Load your edited cn=config.ldif file into the cn=config
  database:

  # slapadd -F /etc/ldap/slapd.d -n0 -l /tmp/openldap-migration/cn=config.ldif

  If the command above has failed, go back to step 2.

  After the slapadd command succeeds, change the permissions on the
  /etc/ldap/slapd.d/ directory to be owned by the openldap user:

  # chown -R openldap:openldap /etc/ldap/slapd.d/

  The file permissions should be correct, but you may want to double
  check that regular files have 0600 (-rw-------) permissions,
  and directories have 0750 (drwxr-x---) permissions.

Now you can proceed with reloading the remaining databases. Migrating your databases to OpenLDAP 2.5.x

For each configured database, you should:

  Locate the backup LDIF file exported by the upgrade process. This
  file will probably be named like:

  /var/backups/slapd-<OLDVERSION>/<SUFFIX>.ldif

  where <SUFFIX> is the database suffix, such as
  dc=example,dc=com, and <OLDVERSION> is the same version as the
  one you used to adjust the configuration file (step 1 of the
  previous section). In our case, the file is named:

  /var/backups/slapd-2.4.57+dfsg-2ubuntu1/dc=example,dc=com.ldif

  Ensure the directory where the database is stored (for example,
  /var/lib/ldap/) is empty. By default, the upgrade process moves
  away the database files to a directory named
  /var/backups/<SUFFIX>-<OLDVERSION>.ldapdb, so you should not see
  any files under /var/lib/ldap/. If you do, just move them away.

  Reload the data using slapadd:

  # slapadd -l /var/backups/slapd-2.4.57+dfsg-2ubuntu1/dc=example,dc=com.ldif

  Make sure the slapadd command succeeded, and then change the
  permissions on the data directory:

  # chown -R openldap:openldap /var/lib/ldap

After all of your databases have been reloaded successfully, you should be able to start the slapd service again:

# service slapd start # service slapd status ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)

   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /usr/lib/systemd/system/slapd.service.d
           └─slapd-remain-after-exit.conf
           /run/systemd/system/service.d
           └─zzz-lxc-service.conf
   Active: active (running) since Wed 2021-08-18 18:19:57 UTC; 2s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1960 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
    Tasks: 3 (limit: 18735)
   Memory: 4.3M
   CGroup: /system.slice/slapd.service
           └─1966 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Aug 18 18:19:57 openldap-test-db-migration systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)… Aug 18 18:19:57 openldap-test-db-migration slapd[1960]: * Starting OpenLDAP slapd Aug 18 18:19:57 openldap-test-db-migration slapd[1965]: @(#) $OpenLDAP: slapd 2.5.6+dfsg-1~exp1ubuntu1 (Aug 17 2021 18:06:00) $

                                                              Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>

Aug 18 18:19:57 openldap-test-db-migration slapd[1966]: slapd starting Aug 18 18:19:57 openldap-test-db-migration slapd[1960]: …done. Aug 18 18:19:57 openldap-test-db-migration systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).

More information

The example above covers a simple scenario that may not reflect what you have installed in production environments. If you face problems that are not covered in this guide, take a look at the slapd package’s README.Debian 39 file, which contains a more extensive guide for troubleshooting some problems.

Tasks: 3 (limit: 18735)
     Memory: 4.3M
     CGroup: /system.slice/slapd.service
             └─1966 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Aug 18 18:19:57 openldap-test-db-migration systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
Aug 18 18:19:57 openldap-test-db-migration slapd[1960]:  * Starting OpenLDAP slapd
Aug 18 18:19:57 openldap-test-db-migration slapd[1965]: @(#) $OpenLDAP: slapd 2.5.6+dfsg-1~exp1ubuntu1 (Aug 17 2021 18:06:00) $
                                                                Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Aug 18 18:19:57 openldap-test-db-migration slapd[1966]: slapd starting
Aug 18 18:19:57 openldap-test-db-migration slapd[1960]:    ...done.
Aug 18 18:19:57 openldap-test-db-migration systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).

</code >
More information

The example above covers a simple scenario that may not reflect what
you have installed in production environments. If you face problems
that are not covered in this guide, take a look at the slapd
package’s README.Debian 39 file, which contains a more extensive guide for troubleshooting some
problems.
|username  |varchar(255)|NO  |   |NULL  |   |
|username_canonical  |varchar(255)|NO  |UNI|NULL  |   |
|email  |varchar(255)|NO  |   |NULL  |   |
|email_canonical  |varchar(255)|NO  |UNI|NULL  |   |
|enabled  |tinyint(1)  |NO  |   |NULL  |   |
|salt  |varchar(255)|NO  |   |NULL  |   |
|password  |varchar(255)|NO  |   |NULL  |   |
|last_login  |datetime  |YES  |   |NULL  |   |
|locked  |tinyint(1)  |NO  |   |NULL  |   |
|expired  |tinyint(1)  |NO  |   |NULL  |   |
|expires_at  |datetime  |YES  |   |NULL  |   |
|confirmation_token  |varchar(255)|YES  |   |NULL  |   |
|password_requested_at|datetime  |YES  |   |NULL  |   |
|roles  |longtext  |NO  |   |NULL  |   |
|credentials_expired  |tinyint(1)  |NO  |   |NULL  |   |
|credentials_expire_at|datetime  |YES  |   |NULL  |   |

Now, you might not need all these fields yourself, but keep in mind that struct passwd structure we saw earlier, and make sure nss-mysql has enough data to fill it :) Besides, the nss-mysql configuration files are flexible enough for you to use default values for anything.

=== Hacking for the LDAP from u-psud ===

Getting the sources from : [[https://sources.debian.org|https://sources.debian.org]] in the file mkhomedir_helper.c change with:

<code c>
int
main(int argc, char *argv[])
{
   struct passwd *pwd;
   struct stat st;

   if (argc < 2) {
    fprintf(stderr, "Usage: %s <username> [<umask> [<skeldir>]]\n", argv[0]);
    return PAM_SESSION_ERR;
   }

   pwd = getpwnam(argv[1]);

   /* SG modified lines */
   char home[] = "/home/";
   char path[200] = "";
   strcat (path, home);
   strcat (path, argv[1]);
   pwd->pw_dir = path;
   printf ("%s", pwd->pw_dir);
   pam_syslog(NULL, LOG_ERR, "Home directory %s is to be created.", pwd->pw_dir);

   /* end of modifications by SG*/

   if (pwd == NULL) {
    pam_syslog(NULL, LOG_ERR, "User unknown.");
    return PAM_CRED_INSUFFICIENT;
   }

   if (argc >= 3) {
    char *eptr;
    errno = 0;
    u_mask = strtoul(argv[2], &eptr, 0);
    if (errno != 0 || *eptr != '\0') {
        pam_syslog(NULL, LOG_ERR, "Bogus umask value %s", argv[2]);
        return PAM_SESSION_ERR;
    }
   }

   if (argc >= 4) {
    if (strlen(argv[3]) >= sizeof(skeldir)) {
        pam_syslog(NULL, LOG_ERR, "Too long skeldir path.");
        return PAM_SESSION_ERR;
    }
    strcpy(skeldir, argv[3]);
   }

   /* Stat the home directory, if something exists then we assume it is
      correct and return a success */
   if (stat(pwd->pw_dir, &st) == 0)
    return PAM_SUCCESS;

   if (make_parent_dirs(pwd->pw_dir, 0) != PAM_SUCCESS)
    return PAM_PERM_DENIED;

   /* original end of function main
   return create_homedir(pwd, skeldir, pwd->pw_dir);
   */
}

And with the file

/* --- authentication management functions (only) --- */

PAM_EXTERN int
pam_sm_open_session (pam_handle_t *pamh, int flags, int argc,
             const char **argv)
{
   int retval;
   options_t opt;
   const void *user;
   struct passwd *pwd;   /* to allow changes in the pwd variable, change from const to --not const--*/
   struct stat St;

   /* Parse the flag values */
   _pam_parse(pamh, flags, argc, argv, &opt);

   /* Determine the user name so we can get the home directory */
   retval = pam_get_item(pamh, PAM_USER, &user);
   if (retval != PAM_SUCCESS || user == NULL || *(const char *)user == '\0')
   {
      pam_syslog(pamh, LOG_NOTICE, "Cannot obtain the user name.");
      return PAM_USER_UNKNOWN;
   }

   /* Get the password entry */
   pwd = pam_modutil_getpwnam (pamh, user);

/* SG modified lines */
/* here begin some new lines to chack that everything is OK */
   char home[] = "/home/";
   char path[200] = "";
   strcat (path, home);
   strcat (path, user);
   pwd->pw_dir = path;
   pam_syslog(NULL, LOG_ERR, "Home directory %s is to be created.", pwd->pw_dir);

/* end of modifications by SG*/

   if (pwd == NULL)
   {
      pam_syslog(pamh, LOG_NOTICE, "User unknown.");
      D(("couldn't identify user %s", user));
      return PAM_CRED_INSUFFICIENT;
   }

   /* Stat the home directory, if something exists then we assume it is
      correct and return a success*/
   if (stat(pwd->pw_dir, &St) == 0) {
      if (opt.ctrl & MKHOMEDIR_DEBUG) {
          pam_syslog(pamh, LOG_DEBUG, "Home directory %s already exists.",
              pwd->pw_dir);
      }
      return PAM_SUCCESS;
   }

   return PAM_SUCCESS;
   /*create_homedir(pamh, &opt, pwd);*/
}

Migration from LDAP2.4.x to LDAP2.5.x

https://discourse.ubuntu.com/t/service-migrating-from-openldap-2-4-x-to-2-5-x/23807

Changes to OpenLDAP 2.5.x

It took more than 10 years for OpenLDAP 2.5.x to be released, and as such it is important to understand the changes that can impact production environments and how to deal with them.

The most important change in this release is the removal of the following backends:

  BDB
  HDB
  Shell

Installations using these backends will need to migrate to a supported backend instead, like LMDB (preferred).

The nssov overlay has also been dropped from the package.

There are also a few additions:

  The new slapd-asyncmeta(5) backend.
  New core overlays: slapd-homedir(5), slapd-otp(5) and
  slapd-remoteauth(5).

# apt-get update
...
# apt-get upgrade
...
Setting up slapd (2.5.6+dfsg-1~exp1ubuntu1) ...
Installing new version of config file /etc/ldap/schema/core.ldif ...
Installing new version of config file /etc/ldap/schema/core.schema ...
Installing new version of config file /etc/ldap/schema/cosine.ldif ...
Installing new version of config file /etc/ldap/schema/cosine.schema ...
Installing new version of config file /etc/ldap/schema/dyngroup.ldif ...
Installing new version of config file /etc/ldap/schema/dyngroup.schema ...
Installing new version of config file /etc/ldap/schema/pmi.ldif ...
Installing new version of config file /etc/ldap/schema/pmi.schema ...
  Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.57+dfsg-2ubuntu1... done.
  Moving old database directories to /var/backups:
  - directory dc=example,dc=com... done.
  Loading from /var/backups/slapd-2.4.57+dfsg-2ubuntu1: 
  - directory dc=example,dc=com... failed.

Loading the database from the LDIF dump failed with the following
error while running slapadd:
    lt_dlopenext failed: (back_bdb) file not found
    config error processing cn=module{0},cn=config: <olcModuleLoad> handler exited with 1
    slapadd: bad configuration directory!
Removing obsolete conffile /etc/ldap/schema/ppolicy.schema ...
Removing obsolete conffile /etc/ldap/schema/ppolicy.ldif ...
Job for slapd.service failed because the control process exited with error code.
See "systemctl status slapd.service" and "journalctl -xeu slapd.service" for details.
invoke-rc.d: initscript slapd, action "start" failed.
× slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
    Drop-In: /usr/lib/systemd/system/slapd.service.d
             └─slapd-remain-after-exit.conf
             /run/systemd/system/service.d
             └─zzz-lxc-service.conf
     Active: failed (Result: exit-code) since Wed 2021-08-18 17:42:39 UTC; 6ms ago
       Docs: man:systemd-sysv-generator(8)
    Process: 1713 ExecStart=/etc/init.d/slapd start (code=exited, status=1/FAILURE)

Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: lt_dlopenext failed: (back_bdb) file not found
Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: config error processing cn=module{0},cn=config: <olcModuleLoad> handler exited with 1
Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: DIGEST-MD5 common mech free
Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: DIGEST-MD5 common mech free
Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: slapd stopped.
Aug 18 17:42:39 openldap-test-db-migration slapd[1718]: connections_destroy: nothing to destroy.
Aug 18 17:42:39 openldap-test-db-migration slapd[1713]:    ...fail!
Aug 18 17:42:39 openldap-test-db-migration systemd[1]: slapd.service: Control process exited, code=exited, status=1/FAILURE
Aug 18 17:42:39 openldap-test-db-migration systemd[1]: slapd.service: Failed with result 'exit-code'.
Aug 18 17:42:39 openldap-test-db-migration systemd[1]: Failed to start LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).
...

As you can see, the upgrade process has failed. You should also have seen a debconf warning saying:

Error while performing post-installation tasks

For more information on possible problematic scenarios and how to address them, please take a look at the README.Debian file (under /usr/share/doc/slapd/).

  You need to locate the backup LDIF file exported during the upgrade
  process. This is the configuration file used by your
  installation. It should be located at:

  /var/backups/slapd-<OLDVERSION>/cn=config.ldif

  <OLDVERSION> should most likely be the latest 2.4.x version you
  had installed before attempting to upgrade to 2.5.x. In our
  example, our file is named
  /var/backups/slapd-2.4.57+dfsg-2ubuntu1/cn=config.ldif.

  Let’s make a copy of the file for working on.

  # mkdir /tmp/openldap-migration
  # cp /var/backups/slapd-2.4.57+dfsg-2ubuntu1/cn=config.ldif /tmp/openldap-migration

  Edit your copy of the cn=config.ldif file to fix the issues noted
  by slapdadd, such as removed or renamed modules or backends.
  In our case, here is what we should do:
      Change olcModuleLoad: back_bdb or back_hdb to back_mdb.
      If you have an olcBackend: bdb or hdb entry, change it to mdb, or
      delete it if you don’t have to override any global LMDB settings.
      For each configured BDB or HDB database:
      Change objectClass: olcBdbConfig or olcHdbConfig to
      olcMdbConfig. Also update structuralObjectClass.
      Change olcDatabase: bdb or hdb to mdb. Also update the
      attribute in the DN, for example:
      olcDatabase={1}mdb,cn=config.
      Delete any olcDbConfig attributes.
      Add the olcDbMaxSize attribute to set the maximum size of the
      database, in bytes. If not configured, the default is 10 MiB.

  To illustrate the changes that are necessary here, here is a diff
  from the original vs. the modified files in the example scenario
  we’re considering in this guide:

– /var/backups/slapd-2.4.57+dfsg-2ubuntu1/cn=config.ldif 2021-08-18 17:42:11.350169777 +0000

+++ /tmp/openldap-migration/cn=config.ldif 2021-08-18 18:18:20.724858076 +0000

  @@ -17,7 +17,7 @@
   objectClass: olcModuleList
   cn: module{0}
   olcModulePath: /usr/lib/ldap
  -olcModuleLoad: {0}back_bdb
  +olcModuleLoad: {0}back_mdb
   structuralObjectClass: olcModuleList
   entryUUID: 216f3358-632c-103b-8f5c-159102fdad19
   creatorsName: cn=config
  @@ -617,9 +617,9 @@
   modifiersName: cn=config
   modifyTimestamp: 20210616202109Z
   
  -dn: olcBackend={0}bdb,cn=config
  +dn: olcBackend={0}mdb,cn=config
   objectClass: olcBackendConfig
  -olcBackend: {0}bdb
  +olcBackend: {0}mdb
   structuralObjectClass: olcBackendConfig
   entryUUID: 216fb710-632c-103b-8f5d-159102fdad19
   creatorsName: cn=config
  @@ -658,10 +658,10 @@
   modifiersName: cn=config
   modifyTimestamp: 20210616202109Z
   
  -dn: olcDatabase={1}bdb,cn=config
  +dn: olcDatabase={1}mdb,cn=config
   objectClass: olcDatabaseConfig
  -objectClass: olcBdbConfig
  -olcDatabase: {1}bdb
  +objectClass: olcMdbConfig
  +olcDatabase: {1}mdb
   olcDbDirectory: /var/lib/ldap
   olcSuffix: dc=example,dc=com
   olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * non
  @@ -672,15 +672,11 @@
   olcRootDN: cn=admin,dc=example,dc=com
   olcRootPW:: e1NTSEF9UDFDMlA1ZDhxbzZuTWR0c0p3NU50c3BBLzJBSm54T0s=
   olcDbCheckpoint: 512 30
  -olcDbConfig: {0}set_cachesize 0 2097152 0
  -olcDbConfig: {1}set_lk_max_objects 1500
  -olcDbConfig: {2}set_lk_max_locks 1500
  -olcDbConfig: {3}set_lk_max_lockers 1500
   olcDbIndex: objectClass eq
   olcDbIndex: cn,uid eq
   olcDbIndex: uidNumber,gidNumber eq
   olcDbIndex: member,memberUid eq
  -structuralObjectClass: olcBdbConfig
  +structuralObjectClass: olcMdbConfig
   entryUUID: 216fc25a-632c-103b-8f5e-159102fdad19
   creatorsName: cn=config
   createTimestamp: 20210616202109Z

  Move away or delete the contents of /etc/ldap/slapd.d/ so that it
  is an empty directory.

  # mkdir /tmp/openldap-migration/old-etc-slapd
  # mv /etc/ldap/slapd.d/* /tmp/openldap-migration/old-etc-slapd

  Load your edited cn=config.ldif file into the cn=config
  database:

  # slapadd -F /etc/ldap/slapd.d -n0 -l /tmp/openldap-migration/cn=config.ldif

  If the command above has failed, go back to step 2.

  After the slapadd command succeeds, change the permissions on the
  /etc/ldap/slapd.d/ directory to be owned by the openldap user:

  # chown -R openldap:openldap /etc/ldap/slapd.d/

  The file permissions should be correct, but you may want to double
  check that regular files have 0600 (-rw-------) permissions,
  and directories have 0750 (drwxr-x---) permissions.

Now you can proceed with reloading the remaining databases. Migrating your databases to OpenLDAP 2.5.x

For each configured database, you should:

  Locate the backup LDIF file exported by the upgrade process. This
  file will probably be named like:

  /var/backups/slapd-<OLDVERSION>/<SUFFIX>.ldif

  where <SUFFIX> is the database suffix, such as
  dc=example,dc=com, and <OLDVERSION> is the same version as the
  one you used to adjust the configuration file (step 1 of the
  previous section). In our case, the file is named:

 ''/var/backups/slapd-2.4.57+dfsg-2ubuntu1/dc=example,dc=com.ldif''

Ensure the directory where the database is stored (for example, /var/lib/ldap/) is empty. By default, the upgrade process moves away the database files to a directory named /var/backups/<SUFFIX>-<OLDVERSION>.ldapdb, so you should not see any files under /var/lib/ldap/. If you do, just move them away. Reload the data using slapadd:

# slapadd -l /var/backups/slapd-2.4.57+dfsg-2ubuntu1/dc=example,dc=com.ldif

  Make sure the slapadd command succeeded, and then change the
  permissions on the data directory:

# chown -R openldap:openldap /var/lib/ldap

After all of your databases have been reloaded successfully, you should be able to start the slapd service again:

# service slapd start
# service slapd status
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
    Drop-In: /usr/lib/systemd/system/slapd.service.d
             └─slapd-remain-after-exit.conf
             /run/systemd/system/service.d
             └─zzz-lxc-service.conf
     Active: active (running) since Wed 2021-08-18 18:19:57 UTC; 2s ago
       Docs: man:systemd-sysv-generator(8)
    Process: 1960 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
      Tasks: 3 (limit: 18735)
     Memory: 4.3M
     CGroup: /system.slice/slapd.service
             └─1966 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Aug 18 18:19:57 openldap-test-db-migration systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
Aug 18 18:19:57 openldap-test-db-migration slapd[1960]:  * Starting OpenLDAP slapd
Aug 18 18:19:57 openldap-test-db-migration slapd[1965]: @(#) $OpenLDAP: slapd 2.5.6+dfsg-1~exp1ubuntu1 (Aug 17 2021 18:06:00) $
                                                                Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Aug 18 18:19:57 openldap-test-db-migration slapd[1966]: slapd starting
Aug 18 18:19:57 openldap-test-db-migration slapd[1960]:    ...done.
Aug 18 18:19:57 openldap-test-db-migration systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).

More information

Table of Contents

LDAP client

Installation des modules nécessaires à l’authentification LDAP

Définition des groupes locaux en plus des groupes LDAP aux utilisateurs LDAP

Creation automatique des répertoires home/LDAP_user

Assigner les groupes locaux aux LDAP_Users

Finaliser

Comment changer la configuration de l'authentification

LDAP request

Migration from LDAP2.4.x to LDAP2.5.x