Directory Service with LDAP [4]: ​​OpenLDAP (I)

Hello friends!. Let's get down to business, and as we always recommend, read the three previous articles in the series:

DNS, DHCP and NTP are the minimum essential services for our simple directory based on OpenLDAP native, works properly on the Debian 6.0 "Squeeze", or in the Ubuntu 12.04 LTS "Precise Pangolin".

Example network:

Lan: 10.10.10.0/24
Dominio: amigos.cu
Servidor: mildap.amigos.cu
Sistema Operativo Servidor: Debian 6 "Squeeze
Dirección IP del servidor: 10.10.10.15
Cliente 1: debian7.amigos.cu
Cliente 2: raring.amigos.cu
Cliente 3: suse13.amigos.cu
Cliente 4: seven.amigos.cu

In Part One we will see:

  • OpenLDAP installation (slapd 2.4.23-7.3)
  • Checks after installation
  • Indices to take into account
  • Data Access Control Rules
  • Generation of TLS Certificates in Squeeze

while in the Second Part we will continue with:

  • Local user authentication
  • Populate the database
  • Manage the database using console utilities
  • Summary so far ...

OpenLDAP installation (slapd 2.4.23-7.3)

The OpenLDAP server is installed using the package slap. We must also install the package ldap-utils, which provides us with some client-side tools, as well as OpenLDAP own utilities.

: ~ # aptitude install slapd ldap-utils

During the installation process, the debconf It will ask us for the password of the administrator or user «admin«. A number of dependencies are also installed; user is created openldap; the initial server configuration is created as well as the LDAP directory.

In earlier versions of OpenLDAP, the daemon configuration slap was done entirely through the file /etc/ldap/slapd.conf. In the version we are using and later, the configuration is done in the same slap, and for this purpose a DIT «Directory Information Tree»Or Directory Information Tree, separately.

The configuration method known as RTC «Real Time Configuration»Real Time Configuration, or as the Method cn = config, allows us to dynamically configure the slap without requiring a restart of the service.

The configuration database consists of a collection of text files in the format LDIF «LDAP Data Interchange Format»LDAP Format for Data Exchange, located in the folder /etc/ldap/slapd.d.

To get an idea of ​​the folder organization slapd.d, let's run:

: ~ # ls -lR /etc/ldap/slapd.d/
/etc/ldap/slapd.d/: total 8 drwxr-x --- 3 openldap openldap 4096 Feb 16 11:08 cn = config -rw ------- 1 openldap openldap 407 Feb 16 11:08 cn = config.ldif /etc/ldap/slapd.d/cn=config: total 28 -rw ------- 1 openldap openldap 383 Feb 16 11:08 cn = module {0} .ldif drwxr-x --- 2 openldap openldap 4096 Feb 16 11:08 cn = schema -rw ------- 1 openldap openldap 325 Feb 16 11:08 cn = schema.ldif -rw ------- 1 openldap openldap 343 Feb 16 11:08 olcBackend = {0} hdb.ldif -rw ------- 1 openldap openldap 472 Feb 16 11:08 olcDatabase = {0} config.ldif -rw ------- 1 openldap openldap 586 Feb 16 11:08 olcDatabase = {- 1} frontend.ldif -rw ------- 1 openldap openldap 1012 Feb 16 11:08 olcDatabase = {1} hdb.ldif /etc/ldap/slapd.d/cn = config / cn = schema: total 40 -rw ------- 1 openldap openldap 15474 Feb 16 11:08 cn = {0} core.ldif -rw ------- 1 openldap openldap 11308 Feb 16 11:08 cn = {1} cosine.ldif -rw ------- 1 openldap openldap 6438 Feb 16 11:08 cn = {2} nis.ldif -rw ------- 1 openldap openldap 2802 Feb 16 11:08 cn = {3} inetorgperson.ldif

If we look at the previous output a bit, we see that the BACKEND used in Squeeze is the database type hdb, which is a variant of bdb "Berkeley Database", and that it is fully hierarchical and supports the renaming of sub-trees. To learn more about the possible back end that supports OpenLDAP, visit http://es.wikipedia.org/wiki/OpenLDAP.

We also see that three separate databases are used, that is, one dedicated to configuration, another to Frontend, and the last one which is the database hdb per se.

Moreover, slap is installed by default with the schematics Core, Cosine, April e internet person.

Checks after installation

In a terminal we calmly execute and read the outputs. We will check, especially with the second command, the configuration deduced from listing the folder slapd.d.

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b cn = config | more: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b cn = config dn
dn: cn = config dn: cn = module {0}, cn = config dn: cn = schema, cn = config dn: cn = {0} core, cn = schema, cn = config dn: cn = {1} cosine , cn = schema, cn = config dn: cn = {2} nis, cn = schema, cn = config dn: cn = {3} inetorgperson, cn = schema, cn = config dn: olcBackend = {0} hdb, cn = config dn: olcDatabase = {- 1} frontend, cn = config dn: olcDatabase = {0} config, cn = config dn: olcDatabase = {1} hdb, cn = config

Explanation of each output:

  • cn = config: Global parameters.
  • cn = module {0}, cn = config: Dynamically loaded module.
  • cn = schema, cn = config: Contains the hard-coded at the level of the system schematics.
  • cn = {0} core, cn = schema, cn = config: The hard-coded of the kernel schematic.
  • cn = {1} cosine, cn = schema, cn = config: The scheme Sew.
  • cn = {2} nis, cn = schema, cn = config: The scheme Nis.
  • cn = {3} inetorgperson, cn = schema, cn = config: The scheme internet person.
  • olcBackend = {0} hdb, cn = config: BACKEND data storage type hdb.
  • olcDatabase = {- 1} frontend, cn = config: Frontend of the database and default parameters for the other databases.
  • olcDatabase = {0} config, cn = config: Configuration database of the slap (cn = config).
  • olcDatabase = {1} hdb, cn = config: Our instance of the database (dc = friends, dc = cu)
: ~ # ldapsearch -x -LLL -H ldap: /// -b dc = example, dc = com dn
dn: dc = friends, dc = cu dn: cn = admin, dc = friends, dc = cu
  • dc = friends, dc = cu: DIT Base Directory Information Tree
  • cn = admin, dc = friends, dc = cu: Administrator (rootDN) of the DIT declared during installation.

Note: The base suffix dc = friends, dc = cu, took it debconf during installation from FQDN server mildap.amigos.cu.

Indices to take into account

The indexing of the entries is carried out to improve the performance of searches on the DIT, with filter criteria. The indexes that we will consider are the minimum recommended according to the attributes declared in the default schemas.

To dynamically modify the indexes in the database, we create a text file in the format LDIF, and later we add it to the database. We create the file olcDbIndex.ldif and we leave it with the following content:

: ~ # nano olcDbIndex.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modify add: olcDbIndex olcDbIndex: uidNumber eq - add: olcDbIndex olcDbIndex: gidNumber eq - add: olcDbIndex olcDbIndex: memberUid eq, olcDbIndex: login eq, olcDbIndex: loginShell eq, olcDbIndex: loginShell eq, olcDbIndex: login - add: olcDbIndex olcDbIndex: uid pres, sub, eq - add: olcDbIndex olcDbIndex: cn pres, sub, eq - add: olcDbIndex olcDbIndex: sn pres, sub, eq - add: olcDbIndex olcDbIndex: givenName, ou pres, eq, sub - add: olcDbIndex olcDbIndex: displayName pres, sub, eq - add: olcDbIndex olcDbIndex: default sub - add: olcDbIndex olcDbIndex: mail eq, subinitial - add: olcDbIndex olcDbIndex: dc eq

We add the indexes to the database and check the modification:

: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f ./olcDbIndex.ldif

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \ cn = config '(olcDatabase = {1} hdb)' olcDbIndex

dn: olcDatabase = {1} hdb, cn = config olcDbIndex: objectClass eq olcDbIndex: uidNumber, gidNumber eq olcDbIndex: memberUid eq, pres, sub olcDbIndex: loginShell eq olcDbIndex: uid presq, sub, eq olcn presq, eq: olcD presqbIndex: cn presq olcDbIndex: sn pres, sub, eq olcDbIndex: givenName, ou pres, eq, sub olcDbIndex: displayName pres, sub, eq olcDbIndex: default sub olcDbIndex: mail eq, subinitial olcDbIndex: dc eq

Data Access Control Rules

Access Control is called the rules that are established so that users can read, modify, add and delete data in the Directory database, while we will call Access Control Lists or «ACL Access Control List»To the policies that configure the rules.

To know which ACLs were declared by default during the installation process of the slap, we execute:

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcDatabase = {1} hdb)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcDatabase = {- 1} frontend)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcDatabase = {0} config)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Each of the previous commands will show us the ACLs that until now we have declared in our Directory. Specifically, the last command shows them all, while the first three give us the access control rules for all three. DIT involved in our slap.

On the subject of ACLs and in order not to make a much longer article, we recommend reading the manual pages man slapd.access.

To guarantee the access of users and administrators to update their entries of loginShell y Geckos, we will add the following ACL:

## We create the olcAccess.ldif file and leave it with the following content: ~ # nano olcAccess.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modify add: olcAccess olcAccess: {1} to attrs = loginShell, gecos by dn = "cn = admin, dc = friends, dc = cu" write by self write by * read

## We add the ACL
: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f ./olcAccess.ldif

# We check the changes
ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Generation of Certificates TLS in Squeeze

To have a secure authentication with the OpenLDAP server, we must do it through an encrypted session which we can achieve by using the TLS “Transport Layer Security” o Secure Transport Layer.

The OpenLDAP server and its clients are able to use the framework TLS to provide protection regarding integrity and confidentiality, as well as to support secure LDAP authentication through the mechanism SASL «Simple Authentication and Security Layer« External.

Modern OpenLDAP servers favor the use of */ StartTLS /* o Start a Secure Transport Layer to the /LDAPS: ///, which is obsolete. Any questions, visit * Start TLS v. ldaps: // * en http://www.openldap.org/faq/data/cache/605.html

Just leave the file as installed by default / etc / default / slapd with the statement SLAPD_SERVICES = »ldap: /// ldapi: ///», with the aim of using an encrypted channel between the client and the server, and the auxiliary applications themselves to administer the OpenLDAP that are installed locally.

The method described here, based on the packages gnutls-bin y ssl-cert it is valid for Debian 6 "Squeeze" and also for Ubuntu Server 12.04. For Debian 7 "Wheezy" another method based on OpenSSL.

The generation of the certificates in Squeeze is carried out as follows:

1.- We install the necessary packages
: ~ # aptitude install gnutls-bin ssl-cert

2.- We create the Primary Key for the Certificate Authority
: ~ # sh -c "certtool --generate-privkey> /etc/ssl/private/cakey.pem"

3.- We create a template to define the CA (Certificate Authority)
: ~ # nano /etc/ssl/ca.info cn = Cuban Friends ca cert_signing_key

4.- We create the CA Self Signed or Self-Signed Certificate for clients
: ~ # certtool --generate-self-signed \ --load-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/ca.info \ --outfile / etc / ssl / certs / cacert.pem

5.- We generate a Private Key for the Server
: ~ # certtool --generate-privkey \ --bits 1024 \ --outfile /etc/ssl/private/mildap-key.pem

Note: Replace "mildap"in the name of the file above by that of your own server. Naming the Certificate and Key, both for the server and for the service that uses it, helps us keep things clear.

6.- We create the file /etc/ssl/mildap.info with the following content:
: ~ # nano /etc/ssl/mildap.info organization = Cuban Friends cn = mildap.amigos.cu tls_www_server encryption_key signing_key expiration_days = 3650

Note: In the previous content we declare that the certificate is valid for a period of time of 10 years. The parameter must be adjusted to our convenience.

7.- We create the Server Certificate
: ~ # certtool --generate-certificate \ --load-privkey /etc/ssl/private/mildap-key.pem \ --load-ca-certificate /etc/ssl/certs/cacert.pem \ --load- ca-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/mildap.info \ --outfile /etc/ssl/certs/mildap-cert.pem

So far we have generated the necessary files, we only have to add to the Directory the location of the Self Signed Certificate cacert.pem; that of the Server Certificate mildap-cert.pem; and the Private Key of the Server mildap-key.pem. We must also adjust the permissions and owner of the generated files.

: ~ # nano /etc/ssl/certinfo.ldif
dn: cn = config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/mildap-cert.pem - add: olcTLSCertificateFile / etc privateKeySCertificateSCertificate / s: olcTLSCertKeyFile / etc. /mildap-key.pem

8.- We add: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f /etc/ssl/certinfo.ldif

9.- We adjust owner and permissions
: ~ # adduser openldap ssl-cert: ~ # chgrp ssl-cert /etc/ssl/private/mildap-key.pem: ~ # chmod g + r /etc/ssl/private/mildap-key.pem: ~ # chmod or /etc/ssl/private/mildap-key.pem

The certificate cacert.pem It is the one that we must copy in each client. For this certificate to be used on the server itself, we must declare it in the file /etc/ldap/ldap.conf. To do this, we modify the file and leave it with the following content:

: ~ # nano /etc/ldap/ldap.conf
BASE dc = friends, dc = cu URI ldap: //mildap.amigos.cu TLS_CACERT /etc/ssl/certs/cacert.pem

Finally and also as a check, we restart the service slap and we check the output of the syslog from the server, to find out if the service was restarted properly using the newly declared certificate.

: ~ # service slapd restart
: ~ # tail / var / log / syslog

If the service does not restart correctly or we observe a serious error in the syslog, let's not be discouraged. We can try to repair the damage or start over. If we decide to start from scratch the installation of the slap, it is not necessary to format our server.

To delete everything that we have done so far for one reason or another, we must uninstall the package slap, and then delete the folder / var / lib / ldap. We must also leave the file in its original version /etc/ldap/ldap.conf.

It is rare that everything works correctly on the first try. 🙂

Remember that in the next installment we will see:

  • Local user authentication
  • Populate the database
  • Manage the database using console utilities
  • Summary so far ...

See you soon friends!.


19 comments, leave yours

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.

  1.   Hugo said

    Teacher!!!
    IT HAPPENED WITH THE TUTO!
    is excellent
    all the LIKES OF THE WORLD FOR YOU.
    😀

    1.    federico said

      Thank you very much, Hugo !!! Wait for the next articles on the subject.

  2.   thisnameisfalse said

    Hello:

    interesting your series of articles.

    I was surprised to read this statement: "Modern OpenLDAP servers prefer the use of StartTLS or Start a Secure Transport Layer to the old TLS / SSL protocol, which is obsolete."

    Do you claim that, in all cases even outside the LDAP scope, STARTTLS is a protection mechanism superior to TSL / SSL?

    1.    federico said

      Thanks for comment. Note that I mean OpenLDAP. I do not overreach. In http://www.openldap.org/faq/data/cache/185.html, you can read the following:

      Transport Layer Security (TLS) is the standard name for the Secure Socket Layer (SSL). The terms (unless qualified with specific version numbers) are generally interchangeable.

      StartTLS is the name of the standard LDAP operation for initiating TLS / SSL. TLS / SSL is initiated upon successful completion of this LDAP operation. No alternative port is necessary. It is sometimes referred to as the TLS upgrade operation, as it upgrades a normal LDAP connection to one protected by TLS / SSL.

      ldaps: // and LDAPS refers to "LDAP over TLS / SSL" or "LDAP Secured". TLS / SSL is initated upon connection to an alternative port (normally 636). Though the LDAPS port (636) is registered for this use, the particulars of the TLS / SSL initiation mechanism are not standardized.

      Once initiated, there is no difference between ldaps: // and StartTLS. They share the same configuration options (excepting ldaps: // requires configuration of a separate listener, see slapd (8) 's -h option) and result in like security services being established.
      Note:
      1) ldap: // + StartTLS should be directed to a normal LDAP port (normally 389), not the ldaps: // port.
      2) ldaps: // should be directed to an LDAPS port (normally 636), not the LDAP port.

      1.    thisnameisfalse said

        Sorry, but I'm still not sure why you claim that: 1) modern servers prefer STARTTLS to SSL / TLS; 2) that STARTTLS is modern, versus SSL / TLS which is obsolete.

        I have been fighting for half a month with the configuration of different mail clients that access the server by SSL (using openssl libraries, as most free software does), with CA certificates in / etc / ssl / certs / and other paraphernalia. And what I've learned is that: 1) STARTTLS only encrypts session authentication, and everything else is sent unencrypted; 2) SSL encrypts absolutely all the content of the session. Therefore, in no case is STARTTLS technically superior to SSL; I would rather be inclined to think otherwise, since the content of your session travels unencrypted over the network.

        Another different thing is that STARTTLS is recommended for other reasons that I do not know: for compatibility with MSWindows, because the implementation is more stable or is better tested ... I don't know. That's why I'm asking you.

        From the citation of the manual you have attached to me in your answer, I see that the difference between ldap: // and ldaps: // is equivalent to the difference between imap: // and imaps: //, or between smtp: // and smtps: //: a different port is used, some additional entry is added in the configuration file, but the rest of the parameters are kept. But that doesn't indicate anything about preferring STARTTLS or not.

        Greetings, and sorry for the reply. I'm just trying to learn a little more.

        1.    federico said

          Look, it is very rare that in my articles I make claims of that caliber without being supported by some serious publication. At the end of the series I will include all the links to documentation that I consider serious, and that I have consulted to write the post. I advance you the following links:

          https://wiki.debian.org/LDAP/OpenLDAPSetup
          Ubuntu ServerGuide https://code.launchpad.net/serverguide
          OpenLDAP-Official http://www.openldap.org/doc/admin24/index.html
          LDAP over SSL / TLS and StartTLS http://tt4cs.wordpress.com/2014/01/18/ldap-over-ssltls-and-starttls/

          And furthermore, I consulted the accompanying documentation that is installed with each package.

          The issue of security in general and the differences between StartTLS and TLS / SSL, are very technical and of such depth that I do not consider myself to have the necessary knowledge to give such explanations. I think we can continue talking via e-mail.

          Furthermore, nowhere do I state that LDAPS: // cannot be used. If you consider it safer, then go ahead !!!

          I can't help you anymore and I really appreciate your comments.

        2.    federico said

          A little more clarity you can get -always about OpenLDAP- in:
          http://www.openldap.org/faq/data/cache/605.html

          The StartTLS extended operation [RFC 2830] is LDAPv3's standard mechanism for enabling TLS (SSL) data confidentiality protection. The mechanism uses an LDAPv3 extended operation to establish an encrypted SSL / TLS connection within an already established LDAP connection. While the mechanism is designed for use with TLSv1, most implementations will fallback to SSLv3 (and SSLv2) if necessary.

          ldaps: // is a mechanism for establishing an encrypted SSL / TLS connection for LDAP. It requires use of separate port, commonly 636. Though originally designed for use with LDAPv2 and SSLv2, many implementations support its use with LDAPv3 and TLSv1. Although there is no technical specification for ldaps: // it is widely used.

          ldaps: // is deprecated in favor of Start TLS [RFC2830]. OpenLDAP 2.0 supports both.
          For security reasons the server should be configured not to accept SSLv2.

  3.   FreeBSDDICK. said

    This will be one of those articles in which users will not comment because since they only watch porn on their Linux stations, they are simply not interested. About ldap I have several related services within the heterogeneous network for the company I work for. Good article!!

    1.    federico said

      Thanks for comment !!!. And your statement regarding the few comments in many of my articles is very true. However, I receive correspondence from interested readers, or from others who download the article for later reading and application.

      It is always very useful to have feedback through comments, even if they are: I saved it for a later reading, interesting, or another opinion.

      regards

  4.   federico said

    The Freeke !!! Thanks for comment. I received your comment in the mail but I don't see it even though I refresh the page several times. Friend, you can try this and the previous articles without problems on Squeeze or Ubuntu Server 12.04. In Wheezy certificates are generated differently, using OpenSSL. But nothing. My regards, brother !!!.

  5.   federico said

    @thisnameisfalse: The best clerk gets a blur. Thanks to your comments, I think that the paragraph in question should be as follows:

    Modern OpenLDAP servers prefer the use of StartTLS or Start a Secure Transport Layer, to the LDAPS: // protocol, which is obsolete. Any questions, visit Start TLS v. ldaps: // en http://www.openldap.org/faq/data/cache/605.html

    regards

  6.   Jose Monge said

    Perfect, right now I have homework on ldap

  7.   walter said

    You cannot put everything in a single file so you can download the complete tutorial

  8.   ever said

    I am a computer technician with extensive experience in Linux, yet I still got lost in the middle of the article. Then I'm going to reread it more carefully. Thank you very much for the tutorial.
    Although it is true that it allows us to understand much more why ActiveDirectory is usually chosen for these things. There is a universe of difference when it comes to simplicity of configuration and implementation.
    regards

  9.   federico said

    Thank you all for commenting !!!
    @jose monge, I hope it helps you
    @walter at the end of all posts, I'll see if I can make a compendium in html or pdf format
    @eVeR the other way around, an OpenLDAP is simpler -even if it doesn't seem like an Active Directory. wait for the next articles and you will see.

  10.   Marcelo said

    A query, I do the installation step by step but when restarting the slapd service, it throws me the following error>

    Jul 30 15:27:37 xxxx slapd [1219]: @ (#) $ OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) $ # 012 # 011buildd @ aatxe: /build/buildd/openldap-2.4.31 .XNUMX / debian / build / servers / slapd
    Jul 30 15:27:37 xxxxx slapd [1219]: UNKNOWN attributeDescription "CHANGETYPE" inserted.
    Jul 30 15:27:37 xxxxx slapd [1219]: UNKNOWN attributeDescription "ADD" inserted.
    Jul 30 15:27:37 xxxxx [1219]: <= str2entry: slap_str2undef_ad (-): empty AttributeDescription
    Jul 30 15:27:37 xxxxx slapd [1219]: slapd stopped.
    Jul 30 15:27:37 xxxxx [1219]: connections_destroy: nothing to destroy.

    1.    x11tete11x said

      you can ask in the forum 😀 http://foro.desdelinux.net/

  11.   petrop said

    For everyone who sees this excellent and well explained post and this problem happens when creating ACLs:
    ldapmodify: invalid format (line 5) entry: "olcDatabase = {1} hdb, dc = config"

    After racking my head searching the internet, it turns out that ldapmodify is the most accurate type out there on the face of the web. It's hysterical with misplaced characters as well as trailing spaces. Without further ado, the advice is to write the condition by side by side that is by X write by self write by * read. If it still doesn't work install Notepad ++> View> Show symbol and finally death to invisible characters. I hope someone helps.

  12.   petrop said

    Generate certificates for Debian Wheezy based on OpenSSL this can serve:
    http://blog.phenobarbital.info/2014/10/openldap-tlsssl-configuracion-basica-y-aseguramiento/