LDAP Configuring a failover LDAP server

  • Tutorial
The Internet Engineering Task Force (IETF)In this article, I will tell you about the 389 Directory Server (aka Fedora Directory Server, aka Redhat Directory Server). It just so happened that LDAP is used to access the directory server . If you have not worked with LDAP, I highly recommend that you read the articles on Wikipedia ( here about the directory service, and here about the LDAP protocol).

So, first briefly about why use the directory service server (hereinafter referred to as the LDAP server). LDAP servers are mainly used for centralized storage of accounts and everything related to them. An LDAP server is a hierarchical database, which means that any data can be stored in it.

It would seem that the logical question is: why LDAP? What makes it difficult to store accounts in MySQL or PostgreSQL? The answer is obvious - nothing =)

But over any RDBMS directory service has a number of advantages:

  • This is the standard. Many applications support authentication / authorization through LDAP;
  • Data is stored as a hierarchical tree, which allows you to do efficient search operations by highlighting the desired part of the tree;
  • The number of read operations is thousands of times higher than the number of write operations, and a huge number of advantages appear in this regard: there is no need to use transactions and rollbacks, replication works without the problems that are inherent in RDBMS;
  • The application should see the same information on all directory service servers, if the server does not store the information needed by the client application, it can request it from another server or redirect the application to another server;
  • Due to the features of the directory service described above, this service scales perfectly horizontally.


The directory service server fell to 389 Directory Server. The history of this LDAP server is closely related to Netscape (if interested, you can read the history here ).



Key features of this LDAP server:

  • Multimaster replication. It is possible to write data to all servers participating in MM-replication at the same time, and replication conflicts are resolved automatically thanks to the changelog database and automatic conflict resolution system. MM replication can be combined with master-slave and cascaded replication, so you can get a flexible and scalable service. Partial replication is also supported, which is extremely useful if we do not want some data to be present on the replica;
  • Powerful ACL engine. Using the ACL, you can specify to whom, when, on which LDAP server, with what attribute and what action to perform. ACLs are stored along with data as operational attributes, which makes replication and backup work for them, as well as for other data.
  • Synchronization with Microsoft Active Directory. Bidirectional synchronization of users, groups and passwords is supported (to synchronize passwords from AD to 389-ds, you must put special software on each domain controller)
  • SSL / TLS. Simple SSL / TLS support will not surprise anyone right now. 389-ds supports authentication / authorization based on SSL certificates. It is also possible to encrypt attributes when writing to disk. By manually entering the key at server startup, this can protect against data leakage by copying files from the database.
  • Server management through LDAP. The server supports configuration by changing the attributes in cn = config, most of the parameters are applied without rebooting the server. Also on the server, you can start backup / restore and other tasks by adding a new entry to cn = tasks, cn = config.
  • Plugins All functionality is implemented as plugins (MM replication, synchronization with AD, ACL, etc.). Writing and adding your plugin is pretty easy, as There is good documentation with examples.


After reviewing the 389 Directory Server, we’ll take a closer look at its structure.

General structure of 389 Directory Server



389 DS consists of several components.

  • The directory server itself. This is an ns-slapd application, it is this process that receives and processes requests from the client, replicates, reads and writes data to the database, transfers control to plugins, etc.
  • Administration Server It manages a directory server. The server provides a management interface via the HTTP (S) protocol, and also provides a web interface for viewing logs and replication status. Physically, these are apache + modules for managing ns-slapd.
  • Administration Console A Java application that connects to the administration server and allows you to configure the directory server through a convenient interface. There is a version for windows and linux, for mac os it works by forwarding an X session from a linux machine.


At first I wanted to write the theoretical and practical parts separately, but then it became clear that the first part would become too boring, and the second too dry. Therefore, immediately after a piece of theory there will be practical application.

So the challenge. You must configure a fault tolerant directory service. To do this, configure two servers, configure multimaster replication between them and raise the moving IP address (pacemaker + openais).

image

If one of the servers becomes unavailable, the other will take over this IP and the service will continue to work.

image

After the server is restored, the data will be replicated to it and the IP address will switch back to LDAP00, or, depending on the cluster settings, will remain on LDAP01.

image

There can be several isolated ns-slapd instances on the same server with their own settings, schema, replication rules, etc. To be able to manage these instances from the management console, each server must have an Administration Server (hereinafter admin server). The admin server itself needs one LDAP server instance, since it stores the run-time configuration there. By default, the admin server configuration is stored along with user data, but I think this is unsafe, so we will have two instances on each server: one will contain the configuration for the admin server, and the second is the data. In this scheme, in the event of a failure of one of the nodes, not only the LDAP service is still operational, but also the ability to manage it.

For our directory service, we use two ldap00 and ldap01 servers. On each of them two LDAP server instances will be installed, one for the needs of admin servers, the second for our data.
The installation plan will be as follows:
  1. Installing the first server on ldap00;
  2. Configure replication on ldap00;
  3. Install and configure the ldap instance on ldap01;
  4. Installing admin server on ldap01;
  5. Install and configure ldap instances to store user data.


Installing the first server on ldap00



Ready-made rpm is compiled in the EPEL repository for Centos, RHEL, and Fedora Core. If you have one of these systems, connect the EPEL repository and complete the installation via yum.

We use SLES, so we had to collect all the packages for this system in our OpenSUSE Build Service. If you have debian / ubuntu - read this document.

Along with 389 DS there is a set of perl scripts that are used to install server instances.

Here is some of them:

  • setup-ds.pl - installs the LDAP server instance, the server is created not connected to the admin server;
  • setup-ds-admin.pl - installs the admin server, if necessary installs the LDAP server instance to store its configuration;
  • register-ds-admin.pl - connects the instance to the admin server, installs the admin server if necessary;
  • remove-ds.pl - removes an instance;
  • remove-ds-admin.pl - removes the admin server and all instances;
  • dsktune - displays system parameters that need to be changed in order to achieve greater performance.


First, run dsktune:

ldap00: ~ # dsktune
389 Directory Server system tuning analysis version 10-AUGUST-2007.

NOTICE: System is x86_64-unknown-linux2.6.27.42-0.1-xen (1 processor).

NOTICE: The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes). This may cause temporary server congestion from lost
client connections.

WARNING: There are only 1024 file descriptors (hard limit) available, which
limit the number of simultaneous connections.

WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.


The utility wrote about the system parameters that need to be tightened. In my case, this is net.ipv4.tcp_keepalive_time and the limit of open files.

tcp_keepalive_time is the time from the last packet sent to the first keepalive sent . With a large value, if the client is "dead", the connection will remain open for a long time (by default 120 minutes). Set this value to 10 minutes.

echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time

Add to /etc/sysctl.conf:

net.ipv4.tcp_keepalive_time = 600

to increase the limit of open files, add to /etc/security/limits.conf:

* - nofile 8192

run dsktune again and make sure everything is ready for installation.

Now run the setup-ds-admin.pl script
We will be asked if we want to install 389 Directory and Administration Server, if we agree with the license, run dsktune again, and finally, a menu for choosing the type of installation appears.

Choose a setup type:

1. Express
Allows you to quickly set up the servers using the most
common options and pre-defined defaults. Useful for quick
evaluation of the products.

2. Typical
Allows you to specify common defaults and options.

3. Custom
Allows you to specify more advanced options. This is
recommended for experienced server administrators only.

To accept the default shown in brackets, press the Enter key.

Choose a setup type [2]:


We select the third item (we are experienced server administrators =))

Next, you will be prompted to specify the FQDN and the name / group from which the LDAP server will be launched.

If you do not yet have a configuration directory server, enter 'No' to
be prompted to set up one.

Do you want to register this software with an existing
configuration directory server? [no]:


Here we are asked if we want to use the existing directory server to store information about the server. Since this is our first server, answer No .

The following are questions about the admin server: administrator ID, password, Administration Domain, we leave the answers to them by default (except for the password).

Then you will need to specify which port the LDAP server will listen on. We agreed that this is an instance that stores only the configuration for the admin server, so we transfer it to port 6389. Next, specify the Directory server identifier. Let's name our instance config-instance. We answer the question about the root tree suffix by default, there will be no root tree in this instance, so you can delete it later.

Then we will have a question about Directory Manager DN.

Directory Manager is the root user in the LDAP server. Each instance has its own local Directory Manager.

The following are questions about the password for Directory Manager, do we want to put example entries in our root suffix and do we want to fill out our new instance with some data, ask the port name, IP address and username from which the admin server will work . After that, they will ask for confirmation one last time and begin the installation.

Configure replication on ldap00



To connect to the server, you need to install and run the 389-console management console.

image

As the Adminstration URL, you need to enter the admin server address and the port that you specified during installation.

Next we get into the server control panel. We now have only one instance, we will choose it.

image

From the management console, delete the suffix dc = edu, dc = scalaxy, dc = local

image

We only have one suffix and the database in which the configuration data for the admin server is located.

Now a little theory about the principles of replication.

Two types of servers, supplier and consumer, participate in replication.

supplier - a server that copies the replica to another server.

server supplier responsibilities:
  • answer customer requests for reading and writing;
  • Maintaining replica change status information
  • initialization of replication to consumer server.

The supplier server should always be available, since recording is done only on this server, and then is replicated to other norths.

If the connection with the supplier server is lost, writing to the directory will become impossible.

consumer is a server that saves a replica from another server. In the case of multimaster replication, two servers are both a supplier and a consumer.

consumer should:
  • answer read requests from clients;
  • forward requests for data updates to the server;
  • upon receipt of a request to add, delete or update a record, the request is forwarded to the supplier server.

Each supplier server has its own changelog, which stores information about all changes that have occurred on the replica.

The supplier server repeats these changes on each consumer server.

Now that we are a little theoretically savvy, you can configure multimaster instance replication with configuration.

Changelog management is disabled by default, it is enabled in the Replication tab. Changelog turns on for all databases at the same time.

Next, enable replication for the NetscapeRoot database. You must specify Replica ID and Supplier DNs.

Supplier DN is the name of the user who is allowed to replicate on the LDAP server. This user must be created on all LDAP servers that participate in the replication multimaster.

The fastest way to do this is through the ldapmodify utility. This utility allows you to modify data in LDAP interactively or to take commands from an ldif file. The answer should be Total, we have succeeded: Immediately create a Replication Agreement for the second server. In the context menu for the NetscapeRoot base, select New Replication Agreement and fill it in the same way: We will be warned that it is impossible to connect to the server (since it is not already), we reach the last item, set Do not initialize consumer .

ldapmodify -h 127.0.0.1 -p 6389 -x -D "cn=root" -W
Enter LDAP Password:
dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:
passwordExpirationTime: 20380119031407Z



adding new entry "cn=replication manager,cn=config"



image



image



Installing and setting up an ldap instance on ldap01



Now you need to configure the second LDAP server. With him a little differently, because the installation of the admin server should already take place in the installed LDAP server and we will perform the initial configuration from the console using the ldapmodify utility (which is a good plus if the task is to figure out how this directory server works).

First, on the second server using the setup-ds.pl script, you need to create an instance that is not controlled by the admin server.

Answers to script questions are similar to the previous ones.

After installing the LDAP server, we connect to it through ldapmodify and configure it.

Connection is approximately as follows:

ldapmodify -h 127.0.0.1 -p 6389 -D "cn=root" -W

1) Turn on changelog :

dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-ldap01/changelogdb


changelogdir should point to the directory with the name of your instance.

2) add the user replication manager : 20380119031407Z means that the password is not expired. 3) Create the netscaperoot suffix : 4) Create the base for the netscaperoot suffix : By the way, 389 DS uses a modified version of the non-relational Berkeley DB database to store directory entries. If you wish, you can read more here . 5) Create root o = NetScapeRoot : 6) Allow replication for o = netscaperoot: Do not forget to change nsDS5ReplicaId to your server number (

dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:
passwordExpirationTime: 20380119031407Z






dn: cn="o=netscaperoot",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: NetscapeRoot
cn: "o=netscaperoot"




dn: cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: o=netscaperoot






dn: o=NetscapeRoot
changetype: add
objectClass: organization
objectClass: top
o: NetscapeRoot




dn: cn=replica,cn="o=netscaperoot", cn=mapping tree, cn=config
changetype: add
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaId: 2
nsDS5ReplicaRoot: o=netscaperoot
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsds5ReplicaChangeCount: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaType: 3


nsDS5ReplicaType - type of replication, 3 - multimaster).

At this point, we already have one way replication configured from ldap00 to ldap01.

The last step will be:

7) Setting up replication from ldap01 to ldap00: nsDS5ReplicaBindDN - username on behalf of which replication will be performed nsDS5ReplicaCredentials - password 8) Initial replication initiation from ldap00 to ldap01: On the first server, execute this command: This command replicates data from ldap00 on ldap01, this operation is required, as the second server is now empty o = netscaperoot. Now we have fully replicated directories with admin server configuration.

dn: cn=Multimaster replication, cn=replica, cn="o=netscaperoot", cn=mapping
tree, cn=config
changetype: add
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Multimaster replication
description: replication for netscaperoot
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsds5replicaChangesSentSinceStartup:
nsDS5ReplicaCredentials:
nsDS5ReplicaHost: ldap00.edu.scalaxy.local
nsDS5ReplicaPort: 6389
nsDS5ReplicaRoot: o=netscaperoot
nsDS5ReplicaTransportInfo: LDAP
nsds5replicaUpdateInProgress: FALSE








dn: cn=Multimaster replication,cn=replica,cn="o=netscaperoot",cn=mapping tree,cn=config
changetype: modify
replace: nsds5beginreplicarefresh
nsds5beginreplicarefresh: start






Installing admin server on ldap01



You need to raise the admin server on the second server. Run the script register-ds-admin.pl

When we are prompted to specify the Configuration directory server URL , enter the LDAP URL of the second server ldap: //ldap01.edu.scalaxy.local: 6389 / o = NetscapeRoot

Further configuration is trivial, follow the instructions in the script.

Install and configure ldap instances to store user data



Now you can connect through the management console to any admin server.

On each server in the Server Group we create a new LDAP server instance, it will be an LDAP server in which we will store our data.

image

We configure multimaster replication between two instances according to the same principle (now you can configure replication both through the GUI and through the console).

Congratulations! You have set up a fail-safe directory service! Next, you need to configure openais + pacemaker to eliminate downtime in the service.

Documentation used:
directory.fedoraproject.org/wiki/Documentation
www.redhat.com/docs/manuals/dir-server

Also popular now: