LDAP Server for ActiveRecord Models

(This was also posted on a blog)

This daemon came about as an add-on to a CRM application that we are developing for a client here at thoughtbot.

I’m standing firmly on the shoulders of others for this one. Specifically, the Ruby LDAP Server, and this post on daemonizing ruby code.

Grab the source from our repository.


The only requirement that the daemon imposes on the AR class is that it implement two methods:

  • Class.search(query) – returns a collection of records that somehow match the string given by query
  • record.to_ldap_entry – returns a hash representing the LDAP information returned to the client. Here’s an example hash:
{ "objectclass" => [ "top", "person", "organizationalPerson", "inetOrgPerson", "mozillaOrgPerson"],
  "uid" => [123],
  "sn" => ["Lastname"],
  "givenname" => ["Firstname"],
  "cn" => [ "Firstname Lastname" ],
  "mail" => [ "email@address.com" ]


The LDAP gateway is a separate process from your Rails application, and is not expected to live under the RAILS_DIR. You can install it in any directory you please, and it can run as any user you need (see note about the port number below).

To configure the gateway, copy the conf/ldap-server.example.yml file to conf/ldap-server.yml and edit that file.

  • rails_dir: RAILS_DIR directory for your rails application.
  • activerecordmodel: Name of the AR Model you’d like to serve.
  • basedn: The LDAP basedn for your server. This is installation specific, and is usually keyed to your domainname. Whatever you put here has to be entered in the client configuration as well.
  • port: The port your server will listen on. If you are not running the server as root, then this port needs to be greater than 1000. 389 is the standard LDAP port.
  • tcp_nodelay: Not sure.
  • preforked_threads: How many threads to run.
  • bind_address: The IP address on which the server will listen. Unless you have security issues, will work just fine.
  • debug: Set this to true to get more verbose startup and logging messages.

Running the Server

Once you’ve configured the server, you can run it with bin/ldap-server.rb start. It should immediately daemonize itself and start logging to log/ldap-server.log. As one of the first log messages, it should state how many records it has access to.

As a final test, you should connect to the server with an addressbook client (such as Thunderbird) and try querying for known records.

Final notes

It looks like the ruby-ldapserver library that I’m using has support for dropping privileges after binding to a port, but I wasn’t able to test that functionality. Also, I believe that you should be able to run this as a different user than the one running your rails application, but that might not be true (you might get log file ownership conflicts). Again, didn’t have time to test that part.

Pair with one of our expert developers to level up your skills with Coaching by thoughtbot. Save time learning best practices and techniques for reducing technical debt in Ember, Ruby, Haskell, and Go in 1-on-1 sessions tailored to your goals.