OpenLDAP – Extra settings

Now I’m going to leave here some steps for extra configurations in OpenLDAP.
The first and not least important is the Log, as installed by default, OpenLDAP does not have a log, and it is a point that was greatly missed during the debugs I had to do to get to the LDAP configuration I wanted, apart from any error debugging. and problems.

Logging configuration is very simple and quick. Create an LDIF file with the settings: (activation_log.ldif)

(https://www.openldap.org/doc/admin23/slapdconf2.html) Search by section: 5.2.1.2. olcLogLevel

mkdir /work/log

cat << EOL > /work/log/activation_log.ldif
dn: cn=config
changeType: modify
replace: olcLogLevel
olcLogLevel: stats
EOL

Import the configuration:

$ ldapadd -Y EXTERNAL -H ldapi:/// -f /work/log/activation_log.ldif

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

For security reasons, it is not at all recommended to perform LDAP queries with the admin user, he is the only one who can change settings, create or delete users, change passwords, etc.
So, in this case, it is recommended to create a Bind DN user that is read only, if you want to restrict the scope by DN, even better, in my case, it is not necessary, the important thing is to know how to do it.

First, we must define an ACL (Access Control Lists) for the ReadOnly bind user. It must have restricted access, read and search only.
I could give this permissions to a Group or OU, but I will create this ACL for “exact” and the user name, which is actually an organizationalRole, which I will create.

Let’s generate a password for the user: For example, just a simple one: 1234qwer

$ slappasswd

New password: 1234qwer
Re-enter new password: 1234qwer
{SSHA}IYJhwtAEaBJM5Epume4A+0fN84iU9eXZ

Now let’s create the user (organizationalRole) with the same name that we defined in the ACL above.

“cn=readonly-bind-dn,ou=ServiceGroups,dc=ldap,dc=devops-db,dc=info”

mkdir -p /work/initial_users

cat << EOL > /work/initial_users/readonly-bind-user.ldif
dn: cn=readonly-bind-dn,ou=ServiceGroups,dc=ldap,dc=devops-db,dc=info
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: readonly-bind-dn
userPassword: {SSHA}IYJhwtAEaBJM5Epume4A+0fN84iU9eXZ
EOL

$ ldapadd -Y EXTERNAL -H ldapi:/// -f /work/initial_users/readonly-bind-user.ldif

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=readonly-bind-dn,ou=ServiceGroups,dc=ldap,dc=devops-db,dc=info"

Simple, it’s already created. Even from any host, you can validate with ldapsearch.
The services that will be installed and with authentication integrated with LDAP, can use this same user and no longer use the admin.

ldapsearch -v -x -H ldaps://ldap.devops-db.info:636 -b "cn=Fausto Branco,ou=UserGroups,dc=ldap,dc=devops-db,dc=info" -D "cn=readonly-bind-dn,ou=ServiceGroups,dc=ldap,dc=devops-db,dc=info" -w "1234qwer"