LDAP is a tree-shaped database system optimized for queries with few updates. This type of DBs is usually suitable for authentication or inventory services.

In this article, I will describe how to perform a basic installation of this service using openldap. Additionally, I will briefly show how to use the shelldap tool to navigate through the tree and how to delete and create entries.

The first thing we must consider is that it is structured in a tree shape, which is called DIT (Data Information Tree). If we are familiar with the SNMP protocol, we will realize that the structure is very similar.

Each object is an instance of an objectClass, and the objectClass contains attributes.

In the following drawing, we can see a configuration of an LDAP tree:

A list of attributes and objectClass can be found here (depending on the schemas included in /etc/openldap/slapd.conf, we will have some objectClass or others at our disposal).

We can see which elements each objectClass has in the schemas:

objectclass ........

A typical schema could be:

Dominio --> Organization unit --> UID
dc=com dc=alfaexploit ou=people uid=kr0m
dc=com dc=alfaexploit ou=servers uid=server01

There can be as many dc as we want: asd.alfaexploit.com

And as many as we want: servers –> HTTP –> server01

The UID attributes are controlled through the objectclass.

• RDN –> Final element of the tree                    uid=kr0m
• DN –> Elements until reaching the RDN                uid=kr0m ou=people dc=alfaexploit dc=com

Now that we have the concepts clear, we can proceed with the software installation:

include     /etc/openldap/schema/core.schema            --> Cuidado con los includes ya que pueden haber dependencias cruzadas!!!
include     /etc/openldap/schema/cosine.schema
include     /etc/openldap/schema/inetorgperson.schema

pidfile     /var/run/openldap/slapd.pid
argsfile    /var/run/openldap/slapd.args

database    hdb
suffix      "dc=alfaexploit,dc=com"

checkpoint  32  30
rootdn      "cn=Manager,dc=alfaexploit,dc=com"         --> Cuando conectemos con este DN se nos permitirá modificar cualquier cosa del LDAP

rootpw      "{SSHA}sAAQc/1EDlk23Vb/stsceOa/EoFd7pghi" --> Salida de slappasswd
directory   /var/lib/openldap-data
index   objectClass eq

We copy the example config file of the database:

The config can be checked with:

config file testing succeeded

NOTE: If it gives problems, we can start it manually with debug level 65535 so we can see where the problem is:

It may also be failing due to the data directory permissions:

We configure the part as a client (to be able to test locally on the LDAP server itself):

BASE dc=alfaexploit,dc=com
URI ldap://ldap.alfaexploit.com:389

IP_SERVER ldap.alfaexploit.com

We check that it works:

# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#

#
dn:
namingContexts: dc=alfaexploit,dc=com --> OK

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

To perform insertions, openldap expects the entry in LDIF syntax:

# Creamos el elemento superior
dn: dc=alfaexploit,dc=com
dc: alfaexploit
description: The best place in the whole world
objectClass: dcObject
objectClass: organization
o: Alfaexploit, Corp.

# Creamos el elemento de tipo organizationUnit
dn: ou=servers,dc=alfaexploit,dc=com
ou: servers
description: All servers in alfaexploit.com
objectclass: organizationalUnit

# Anyadimos un servidor al elemento
dn: uid=server01,ou=servers,dc=alfaexploit,dc=com
objectclass: inetOrgPerson
cn: server01
sn: serve01
uid: server01
displayName: HTTP-server01

NOTE: The LDAP server will NOT allow us access even using rootdn credentials if there is no data in the tree, to avoid this we will ALWAYS perform an initial data load!!

We perform the insertion:

Enter LDAP Password:

adding new entry "dc=alfaexploit,dc=com"
adding new entry "ou=servers,dc=alfaexploit,dc=com"
adding new entry "uid=server01,ou=servers,dc=alfaexploit,dc=com"

If we want to debug the output:

To check that it has been inserted:

version: 1

#
# LDAPv3
# base <dc=alfaexploit,dc=com> (default) with scope subtree
# filter: objectClass=inetOrgPerson
# requesting: ALL
#

# server01, servers, alfaexploit.com
dn: uid=server01,ou=servers,dc=alfaexploit,dc=com
objectClass: inetOrgPerson
cn: server01
sn: serve01
uid: server01
displayName: HTTP-server01

# search result

# numResponses: 2
# numEntries: 1

A very useful tool is shelldap, which allows us to navigate the tree and perform administrative tasks on it:

~ > TAB
cat copy delete exit id mkdir passwd rm touch 
cd cp edit grep list move pwd search vi 
clear create env help ls mv read setenv whoami 

~ > ls
ou=servers/

~ > cd ou=servers

ou=servers,~ > ls

uid=server01
ou=servers,~ > cat uid=server01
dn: uid=server01,ou=servers,dc=alfaexploit,dc=com
objectClass: inetOrgPerson
cn: server01
displayName: HTTP-server01
sn: serve01
uid: server01

ou=servers,~ > rm uid=server01
Are you sure? [N/y]: y
uid=server01,ou=servers,dc=alfaexploit,dc=com: Success

ou=servers,~ > ls
ou=servers,~ > create organizationalUnit
dn: ou=HTTP_SERVERS,ou=servers,dc=alfaexploit,dc=com
objectClass: organizationalUnit
ou: HTTP_SERVERS

Success

ou=servers,~ > ls
ou=HTTP_SERVERS


ou=servers,~ > cd ou=HTTP_SERVERS
ou=HTTP_SERVERS,ou=servers,~ > create inetOrgPerson
dn: cn=http_server_01,ou=HTTP_SERVERS,ou=servers,dc=alfaexploit,dc=com
objectClass: inetOrgPerson
cn: http_server_01
sn: http_server_01

Success


ou=HTTP_SERVERS,ou=servers,~ > ls
cn=http_server_01

If objects of various types are created and one of them is in a schema that was not included in the LDAP server, the corresponding options for that schema will not appear.

If at any time we need to dump the LDAP tree from the LDAP server itself, we can do so:

With this, we already have our basic LDAP server. In future deliveries, I will explain how we can have an environment with a VIP and a second LDAP server on standby.