How to Configure OpenLDAP with 2 Hosts on Mirror Mode

OpenLDAP is a free, open source implementation of the Lightweight Directory Access Protocol (LDAP) developed by the OpenLDAP Project. In other words, it is a protocol for managing related information from a centralized location through the use of a file and directory hierarchy.

It functions in a similar way to a relational database in certain ways and can be used to organize and store any kind of information. LDAP is commonly used for centralized authentication. In this article, we will consider OpenLDAP configuration with two hosts on Mirror Mode.

OpenLDAP has three main components:

- slapd – stand-alone LDAP daemon and associated modules and tools
- libraries implementing the LDAP protocol and Basic Encoding Rules
- client software : ldapsearch, ldapadd, ldapdelete, and others.

Before we get started

LDAP is an Internet protocol that email and other programs use to look up contact information from a server. It is released under OpenLDAP public license, it is available for all major Linux distributions, AIX, Android, HP-UX, OS X, Solaris, Windows and z/OS.

LDAP is not limited to store the information, it is also used as a backend database for “single sign-on” where one password for a user is shared between many services. In this tutorial, we will install and configure OpenLDAP together with Mirror Mode replication on CentOS 6.8.

1) Openldap Installation

On CentOS and RedHat, use yum install as shown below, to install the openldap related packages.

yum -y install openldap openldap-servers openldap-clients

-y flag – Assume yes if prompted
openldap-servers – This is the main LDAP server
openldap-clients – This contains all required LDAP client utilities
openldap – This package contains the LDAP support libraries

Note: For Web UI you need to install phpldapadmin package. We assume that httpd daemon is already installed on the machine. If not, please install it in order to access Web UI.

phpLDAPadmin (also known as PLA) is a web-base LDAP client. It provides easy, anywhere-accessible, multi-language administration for your LDAP server.

Its hierarchical tree-viewer and advanced search functionality make it intuitive to browse and administer your LDAP directory. Since it is a web application, this LDAP browser work on many platforms, making your LDAP server easily manageable from any location.

To conclude, phpLDAPadmin is the perfect LDAP browser for the LDAP professional and novice alike. Its user base consists mostly of LDAP administration professionals. To install it you need to run following command:

yum -y install phpldapadmin

2) Ldap Configuration

To start with, we will update /etc/openldap/ldap.conf file. The ldap.conf configuration file is used to set system-wide defaults to be applied when running ldap clients. Users may create an optional configuration file, ldaprc or .ldaprc, in their home directory which will be used to override the system-wide defaults file.

For the basic set up we need to change only 2 parameters: BASE and URI. You can use any editor at your convenience. In this example we will use vi.

vi /etc/openldap/ldap.conf

BASE dc=example,dc=com
URI ldap://localhost

BASE – specifies the default base DN to use when performing ldap operation. The base must be specified as a Distinguished Name in LDAP format.

URI - Specifies the URI(s) of an LDAP server(s) to which the LDAP library should connect. The URI scheme may be any of ldap, ldaps or ldapi, which refer to LDAP over TCP, LDAP over SSL (TLS) and LDAP over IPC (Unix domain sockets), respectively. Each server's name can be specified as a domain-style name or an IP address literal. Optionally, the server's name can followed by a ':' and the port number the LDAP server is listening on. If no port number is provided, the default port for the scheme is used (389 for ldap://, 636 for ldaps://). For LDAP over IPC, name is the name of the socket, and no port is required, nor allowed.Next thing, we need to copy slapd.conf.obsolete file to /etc/openldap/ directory.

Later on, we will update this file.

cp /usr/share/openldap-servers/slapd.conf.obsolete /etc/openldap/slapd.conf

The slapd.conf file consists of three type of configuration information: global, backend specific, and database specific. Global information is specified first, followed by information associated with a particular backend type, which is then followed by information associated with a particular database instance. Global directives can be overridden in backend and/or database directives, and backend directives can be overridden by database directives.
Blank lines and comment lines beginning with a '#' character are ignored. If a line begins with whitespace, it is considered a continuation of the previous line (even if the previous line is a comment).

Note: This step is optional.

It appears that increasingly the OpenLDAP advice is to use DB_CONFIG in preference to other configuration attributes or slapd.conf directives. Where this is possible, it is noted in each directive.

The decision as to whether or not to use a DB_CONFIG file is simple - if you care about performance use it. If you don't care - forget it. BUT if you elect not to use a DB_CONFIG you MUST use a checkpoint directive. Increasingly the OpenLDAP advice seems to be to use DB_CONFIG rather that pass parameters through via slapd.conf.

cp /usr/share/openldap-servers/DB_CONFIG.example /etc/openldap/DB_CONFIG

Then, we need to generate our LDAP root password with slappasswd command. Simply run:

slappasswd

Slappasswd is used to generate a userPassword value suitable for use with ldapmodify, slapd.conf rootpwconfiguration directive or the slapd-config olcRootPW configuration directive. Once you run the command and prompted the password, you will see SSHA password. We will use this root password through this article. So make a note of this and keep it aside.

Now, we need to amend /etc/openldap/slapd.conf file with your DN and password you've just generated. Basically, there would be 2 rows where you need your domain name:

vi /etc/openldap/slapd.conf

navigate to “database definitions” section and update suffix and rootdn with your DN and paste full SSHA password next to the rootpw

suffix "dc=example,dc=com"
rootdn "cn=manager,dc=example,dc=com"
rootpw {SSHA}gHuk69PP7Hxh4mglbRdkg47GQrfBhlt6

Next step, we will amend /etc/phpldapadmin/config.php file to access Web GUI. Please find the following rows and update them as follows:

// $servers->setValue('login','attr','dn');
$servers->setValue('login','attr','uid');
→
$servers->setValue('login','attr','dn');
// $servers->setValue('login','attr','uid');

Here we are specifying an attribute to use when logging in. By default, phpLDAPadmin will search for uid=username (if you login as username). If you leave it blank or specify 'dn' as we just did, phpLDAPadmin will use full DN (that we provided in slapd.conf).

Also, please uncomment following line and add IP address:

$servers->setValue('server','host','127.0.0.1');

The last thing we need to do to access phpLDAPadmin Web UI is to update /etc/httpd/conf.d/phpldapadmin.conf file to list IP addresses that are allowed to connect to the Web UI. By default, the file should looks like following:

#
# Web-based tool for managing LDAP servers
#
Alias /phpldapadmin /usr/share/phpldapadmin/htdocs
Alias /ldapadmin /usr/share/phpldapadmin/htdocs

Order Deny,Allow
Deny from all
Allow from 127.0.0.1
Allow from ::1

If not, please update is as described above.

3) Test and Run

Please run following command set to perform a full test of configuration:

rm -rf /etc/openldap/slapd.d/* chown -R ldap. /etc/openldap/slapd.d/ chown -R ldap. /var/lib/ldap/ slaptest -u slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/

If test run successfully, please proceed to the next step – enabling LDAP for the auto start of service on system boot and LDAP service start

chkconfig slapd on service httpd restart service slapd restart

You can verify whether LDAP is running with netstat command:

netstat -antup | grep -i 389

Now, we need to create some objects in our LDAP. Please create several .ldif files with the following content:

Organization.ldif
dn: dc=example,dc=com
dc: corp
o: corp
objectclass: dcObject
objectclass: organization

Department.ldif 
dn: ou=department,dc=example,dc=com
objectclass: organizationalUnit
objectclass: top
ou: hadoop

Groups.ldif
dn: ou=groups,ou=department,dc=example,dc=com
objectclass: organizationalUnit
objectclass: top
ou: groups

System_admin.ldif
dn: cn=system_admin,ou=groups,ou=department,dc=example,dc=com
cn: system_admin
gidnumber: 502
memberuid: admin1
memberuid: admin2
objectclass: posixGroup
objectclass: top

Users.ldif
dn: ou=users,ou=department,dc=example,dc=com
objectclass: organizationalUnit
objectclass: top
ou: users

Admin1.ldif
dn: uid=admin1,ou=users,ou=department,dc=example,dc=com
cn: admin1
gidnumber: 502
givenname: Admin1
homedirectory: /home/users/admin1
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: Admin1
uid: admin1
uidnumber: 5001
userpassword: password

Admin2.ldif
dn: uid=admin2,ou=users,ou=department,dc=example,dc=com
cn: admin2
gidnumber: 502
givenname: Admin2
homedirectory: /home/users/admin2
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: Admin2
uid: admin2
uidnumber: 5002
userpassword: password

Now, you need to add these objects to your LDAP server by running following command for each file:

ldapadd -x -W -D “cn=manager,dc=example,dc=com” -f

4) Mirror Mode replication

Mirror Mode is a hybrid configuration that provides all of the consistency guarantees of single-master replication, while also providing the high availability of multi-master. In Mirror Mode two providers are set up to replicate from each other (as a multi-master configuration), but an external frontend is employed to direct all writes to only one of the two servers. The second provider will only be used for writes if the first provider crashes, at which point the frontend will switch to directing all writes to the second provider. When a crashed provider is repaired and restarted it will automatically catch up to any changes on the running provider and resync.

Arguments for Mirror Mode

Provides a high-availability (HA) solution for directory writes (replicas handle reads).
As long as one provider is operational, writes can safely be accepted.
Provider nodes replicate from each other, so they are always up to date and can be ready to take over (hot standby).
Syncrepl also allows the provider nodes to re-synchronize after any downtime.

Arguments against Mirror Mode

Mirror Mode is not what is termed as a Multi-Master solution. This is because writes have to go to just one of the mirror nodes at a time.
Mirror Mode can be termed as Active-Active Hot-Standby, therefore an external server (slapd in proxy mode) or device (hardware load balancer) is needed to manage which provider is currently active.
Backups are managed slightly differently.

Before we can start Mirror Mode you need to perform the same installation and configuration steps provided in this article (except the part with *.ldif part, all objects will be replicated after the Mirror Mode is set up) on another host; we will call it – slave host.

Once you have successfully installed and configured LDAP on slave host, you need to update master's (first configured host) /etc/openldap/slapd.conf file as following:

a. Uncomment modueload syncprov.la
b. Add following configuration to the of the file:

##### Mirror Mode
serverID    001

# Consumer
syncrepl rid=001
provider=ldap://slave.example.com
bindmethod=simple
binddn="cn=manager,dc=example,dc=com"
credentials="slave_userPassword_from_slappasswd"
searchbase="dc=example,dc=com"
attrs="*,+"
type=refreshAndPersist
interval=00:00:01:00
retry="60 +"
# Provider
overlay syncprov
syncprov-checkpoint 50 1
syncprov-sessionlog 50

mirrormode on

Then, you need to update slaves /etc/openldap/slapd.conf as following:

a. Uncomment moduleload syncprov.la
b. Add following configuration to the end of the file:

##### Mirror Mode
serverID    002

# Consumer
syncrepl rid=001
provider=ldap://master.example.com
bindmethod=simple
binddn="cn=Manager,dc=example,dc=com"
credentials="master_userPassword_from_slappasswd"
searchbase="dc=example,dc=com"
attrs="*,+"
type=refreshAndPersist
interval=00:00:01:00
retry="60 +"
# Provider
overlay syncprov
syncprov-checkpoint 50 1
syncprov-sessionlog 50

mirrormode on

That's it! Please run the full test with provided command set and check your slaves objects.

Conclusion

You will now have a directory architecture that provides all of the consistency guarantees of single-master replication, while also providing the high availability of multi-master replication. It's simple really; each Mirror Mode node is setup exactly the same, except that the serverID is unique, and each consumer is pointed to the other server.