Differences

This shows you the differences between two versions of the page.

--- doc:appunti:linux:sa:sldap_2_5 [2023/12/02 11:09] – [Adding a second (new) database] niccolo
+++ doc:appunti:linux:sa:sldap_2_5 [2023/12/02 12:31] (current) – [Enable SSL] niccolo
@@ Line 15: / Line 15: @@
 FIXME La **[[https://discourse.ubuntu.com/t/service-migrating-from-openldap-2-4-x-to-2-5-x/23807|Service - Migrating from OpenLDAP 2.4.x to 2.5.x]]** non ha funzionato; fallisce quando si tenta di ricaricare il database **dc=rigacci,dc=org.ldif** con il comando **slapadd**.
-===== Restore from the backup file =====
+Per ripristinare il servizio si sono eseguite ex-nove tutte le operazoni necessarie, in particolare:
-The upgrade process created a backup of the existing LDAP database into the **/var/backups/slapd-2.4.57+dfsg-3+deb11u1/** directory. In our case there is a single file **dc=rigacci,dc=org.ldif** containing all the required entries. In the following examples we extracted from the file the logically different items to be restored.
+  * Caricato lo schema **mozillaAbPersonAlpha**.
+  * Creato il database #2 per gestire il suffisso **ou=Addressbook,dc=rigacci,dc=org**.
+  * Creata la organizationalUnit **Addressbook**.
+  * Creata la inetOrgPerson **cn=guest**.
+  * Caricate tutte le entry objectClass **mozillaAbPersonAlpha**.
-Beware that the restore will be not a perfect copy of the previous database. Several items must be purged from the backup file before feeding it back to the LDAP server because they are not allowed to be set directly. They are:
+===== (Re)installation from scratch =====
-  * structuralObjectClass
+By installing the **slapd** package from scratch, an empty LDAP database is created using the **dn** (//distinguished name//) **dc=lan,dc=rigacci,dc=net** (i.e. the output of the ''%%hostname --domain%%'' - which in our case is ''lan.rigacci.net'' - is used to generate the **dc** //domain content// parts of the name). During configuration you are asked for a password to be assigned to the admin user, i.e. to the item **cn=admin,dc=rigacci,dc=net**.
-  * entryUUID
-  * creatorsName
-  * createTimestamp
-  * entryCSN
-  * modifiersName
-  * modifyTimestamp
-Once a snippet of the file is ready, you can feed it to the slapd service with the following command:
+The LDAP database is numbered as **#1**; initially it contains only the root objext **objectClass: organization**. You can view it with the command
 <code>
-ldapadd -x -W -D "cn=admin,ou=Addressbook,dc=rigacci,dc=org" -f file.ldif
+slapcat -n1
 </code>
-==== Create the Addressbook organizationalUnit ====
+If you run **dpkg-reconfigure slapd** it is possibile to generate the LDAP database again; you can change the distinguished name, assign a different organization name and the admin password.
-<file>
+Actually a special database numbered **#0** named **cn=config** is created too. Here you can view the configuration options of the database #1, the (hashed) password of the admin user, etc. You can view that special database using:
-dn: ou=Addressbook,dc=rigacci,dc=org
-objectClass: top
-objectClass: organizationalUnit
-ou: Addressbook
-</file>
-==== Create the Addressbook guest person ====
+<code>
+slapcat -n0
+</code>
-<file>
+Reading the dump of database #0, you can see that the **cn=config** database has the **olcRootDN: cn=admin,cn=config**, but it does not have an **olcRootPW**, so you cannot modify the config database connecting with a login/password pair. See below on how to modify the **cn=config** database (e.g. to add a new database backend).
-dn: cn=guest,ou=Addressbook,dc=rigacci,dc=org
-objectclass: top
-objectclass: person
-objectclass: organizationalPerson
-objectclass: inetOrgPerson
-sn: guest
-cn: guest
-userPassword: ReadOnlySecret
-</file>
+===== Enable SSL =====
-==== Load all the mozillaAbPersonAlpha entries ====
+Create a self signed certificate or get it from some provider, like **[[https://letsencrypt.org/|Let's Encrypt]]**. Copy the files into **/etc/ldap/ssl/** and give them permissions for the //openldap// user.
-Each mozillaAbPersonAlpha item is somethink like this, after removing the unallowed tags:
+Create the following file **config-ssl.ldif**:
 <file>
-dn: cn=Niccolo Rigacci,ou=Addressbook,dc=rigacci,dc=org
+dn: cn=config
-objectClass: top
+changetype: modify
-objectClass: person
+replace: olcTLSCertificateFile
-objectClass: organizationalPerson
+olcTLSCertificateFile: /etc/ldap/ssl/fullchain.pem
-objectClass: inetOrgPerson
+-
-objectClass: mozillaAbPersonAlpha
+replace: olcTLSCertificateKeyFile
-cn: Niccolo Rigacci
+olcTLSCertificateKeyFile: /etc/ldap/ssl/privkey.pem
-givenName: Niccolo
+-
-sn: Rigacci
+replace: olcTLSCACertificatePath
-mail: niccolo@rigacci.org
+olcTLSCACertificatePath: /etc/ssl/cert
-telephoneNumber: 055-0118525
-mobile: 327-5556667
-facsimileTelephoneNumber: 055-0118525
-homePhone: 055-8979395
-mozillaWorkUrl: http://www.rigacci.org/
 </file>
-===== (Re)installation from scratch =====
+and load it into the slapd 2.5 configuration:
-By installing the **slapd** package from scratch, an empty LDAP database is created using the **dn** (//distinguished name//) **dc=lan,dc=rigacci,dc=org** (i.e. the output of the ''%%hostname --domain%%'' - which in our case is ''lan.rigacci.org'' - is used to generate the **dc** //domain content// parts of the name). During configuration you are asked for a password to be assigned to the admin user, i.e. to the item **cn=admin,dc=rigacci,dc=org**.
-The LDAP database is numbered as **#1**; initially it contains only the root objext **objectClass: organization**. You can view it with the command
 <code>
-slapcat -n1
+ldapmodify -Y EXTERNAL -H ldapi:/// -f config-ssl.ldif
 </code>
-If you run **dpkg-reconfigure slapd** it is possibile to generate the LDAP database again; you can change the distinguished name, assign a different organization name and the admin password.
+Enable ldaps into **/etc/default/slapd**:
-Actually a special database numbered **#0** named **cn=config** is created too. Here you can view the configuration options of the database #1, the (hashed) password of the admin user, etc. You can view that special database using:
+<file>
+SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"
+</file>
-<code>
+Restart the slapd service.
-slapcat -n0
-</code>
-Reading the dump of database #0, you can see that the **cn=config** database has the **olcRootDN: cn=admin,cn=config**, but it does not have an **olcRootPW**, so you cannot modify the config database connecting with a login/password pair. See below on how to modify the **cn=config** database (e.g. to add a new database backend).
 ===== Adding a second (new) database =====
@@ Line 108: / Line 84: @@
 Using ''ldapadd'' to create a new database, requires the privilege to modify the ''cn=config'' database. The default Debian installation does not assign a password to the ''cn=admin,cn=config'' entry, so you cannot use a standard TCP connection to the server, you must use the **EXTERNAL SASL mechanism**.
-Here it is the example of an LDIF file to create a new DIT database, supposed to contain an addressbook. We will use the MDB backend and the ''/var/lib/ldap/abook/'' directory will contain the data. The database will be populated later; we will add at least the ''cn=admin,ou=Addressbook,dc=rigacci,dc=org'' item to be used as an administrator account with full privileges on the database itself. Beware that the **olcSuffix** must not be a child of an already existing database suffix (notice that we used the ''org'' top level domain instead of ''net'' used in the previous examples).
+Here it is the example of an LDIF file to create a new DIT database, supposed to contain an addressbook. We will use the MDB backend and the ''/var/lib/ldap/abook/'' directory will contain the data. The database will be populated later. The item ''cn=admin,ou=Addressbook,dc=rigacci,dc=org'' is defined here and it will be used as an administrator account with full privileges on the database itself. Beware that the **olcSuffix** must not be a child of an already existing database suffix (notice that we used the ''org'' top level domain instead of ''net'' used in the previous examples).
 The file was named **abook-db.ldif**:
@@ Line 130: / Line 106: @@
 </file>
-Notice we will grant read-only privileges to an item **cn=guest** in the same LDAP tree. Before creating the database we create the destination directory and assign the required permissions:
+Notice we will grant read-only privileges to an item **cn=guest** in the same LDAP tree; that item will be added into the database later. Before creating the database we create the destination directory and assign the required permissions:
 <code>
@@ Line 216: / Line 192: @@
 </code>
+===== Restore from the backup file =====
+The upgrade process created a backup of the existing LDAP database into the **/var/backups/slapd-2.4.57+dfsg-3+deb11u1/** directory. In our case there is a single file **dc=rigacci,dc=org.ldif** containing all the required entries. In the following examples we extracted from the file the logically different items to be restored.
+Beware that the restore will be not a perfect copy of the previous database. Several tags must be purged from the backup file before feeding it back to the LDAP server because they are not allowed to be set directly. They are:
+  * structuralObjectClass
+  * entryUUID
+  * creatorsName
+  * createTimestamp
+  * entryCSN
+  * modifiersName
+  * modifyTimestamp
+Once a snippet of the file is ready, you can feed it to the slapd service with the following command:
+<code>
+ldapadd -x -W -D "cn=admin,ou=Addressbook,dc=rigacci,dc=org" -f file.ldif
+</code>
+In the following three paragraphs we will see what is needed for a full restore.
+==== Create the Addressbook organizationalUnit ====
+<file>
+dn: ou=Addressbook,dc=rigacci,dc=org
+objectClass: top
+objectClass: organizationalUnit
+ou: Addressbook
+</file>
+==== Create the Addressbook guest person ====
+<file>
+dn: cn=guest,ou=Addressbook,dc=rigacci,dc=org
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+objectclass: inetOrgPerson
+sn: guest
+cn: guest
+userPassword: ReadOnlySecret
+</file>
+==== Load all the mozillaAbPersonAlpha entries ====
+Each mozillaAbPersonAlpha item is somethink like this, after removing the unallowed tags:
+<file>
+dn: cn=Niccolo Rigacci,ou=Addressbook,dc=rigacci,dc=org
+objectClass: top
+objectClass: person
+objectClass: organizationalPerson
+objectClass: inetOrgPerson
+objectClass: mozillaAbPersonAlpha
+cn: Niccolo Rigacci
+givenName: Niccolo
+sn: Rigacci
+mail: niccolo@rigacci.org
+telephoneNumber: 055-0118525
+mobile: 327-5556667
+facsimileTelephoneNumber: 055-0118525
+homePhone: 055-8979395
+mozillaWorkUrl: http://www.rigacci.org/
+</file>
+==== Testing an ldapsearch ====
+Finally you can test if the LDAP database is working doing a full search with **ldapsearch**:
+<code bash>
+ldapsearch -W \
+    -H ldap://127.0.0.1/ \
+    -D "cn=guest,ou=Addressbook,dc=rigacci,dc=org" \
+    -b 'ou=Addressbook,dc=rigacci,dc=org'
+</code>
+The **ldap** protocol is on port **389/tcp**, **ldaps** is on **636/tcp**.
 ===== Web References =====