1

I'm using LDAP used (mostly) as a backend for user authentication (pam, samba, web,...).

Now I'm trying to migrate the LDAP-database to a new root-dn.

  • old root-dn: dc=local

  • new root-dn: dc=example,dc=com

The process is simple enough,e.g.

  • dump to ldif

  • change the root-dn (e.g. with sed) in the ldif file

  • drop old database

  • import ldif

Now, I would like to ensure, that the numerous clients don't experience excessive downtime (due to the changed root-dn), since (afaict) all clients have the root-DN hardcoded in the configurations.

I'm worried because when I switch the root-dn, I have to manually update each client, so the last client updated will have a prolonged downtime (well, not downtime, but users won't be able to authenticate...)

So I was thinking about exposing my tree under both the old and new root-dn until the configuration on all clients has been migrated, eventually using a proxy.

Is my approach correct (e.g. best practice)? Are there (better) alternatives?

2 Answers 2

1

During my time in Univention's Professional service I worked on multiple similar projects and the one thing missing from the problem description is, what the LDAP is actually used for.

The first question you would need to check is

  • whether or not your services are fault tolerant enough to survive a short outage
  • Is the LDAP base hardcoded into any place

Once you have determined what's attached to the LDAP server, you can plan the downtime for each service.

For the actual downtime, I found that a break is often better then running the two systems in parallel. Running the two LDAP servers in parallel, or two LDAP basis on one system, often entails that you need to make changes in both systems and to keep them in sync and end up with more work and problems then a sudden shift would be.

If you want to minimize the downtime, virtualization or a second physical server would be the way to go. Clone the System with your LDAP and then remove it from the network. Make the changes on the clone as you described yourself. Change the IP and hostname of the new server to match the productive ldap server. Preferably test your most applications whether there are any implications. Power down the old server and attach the network to the new one. Change applications that don't fallover automatically.

During the whole procedure any changes in the LDAP of the old server needs to be replicated to the new one as well. Just be aware that some services, computers (esp. Windows attached to Samba) or users might change their passwords without telling an admin.

Downtime for the LDAP can be minimized to a couple of seconds, if you switch the virtual network interface with a script.

1
  • i updated my question to answer your remarks (i'm using ldap for user auth; root-dn is hardcoded in all clients)
    – umläute
    Apr 1, 2015 at 7:34
0

Your approach is entirely reasonable.

You may lose clout to migrate legacy clients, and in my limited experience (Oracle DS) proxy LDAP brings new challenges, but this is a known way of handling such a transition.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .