Sunday, June 23, 2013 - 03:44
Written by

For some time i've been trying to make my organisations contact list accessible outside of CiviCRM. Why you may ask?

Well, mainly convenience, but also for reducing duplication, maintaining a personal address book, an organisational address book and a CRM will mean inconsistent information, duplicates, contacts in one place and not the other etc. On the convenience side of things, it means potentially having access to your CiviCRM contacts in your email program, phone and many other places LDAP can be utilised.

Initially I tried the google apps sync extension but that had a couple of pitfalls, firstly you need google apps (which you may not have), if you do have an account, you will need a paid account (again not necessarily a blocker), but the main problem I hit was that the extension can only write (a Google limitation) to your accounts directory, which doesn't seem to be too accessible through any other external applications apart from Android contact applications. This may be enough for most people, but it didn't match my requirements, if it matches yours then follow the instructions on that extension, it's pretty easy to set up.

So then I looked into the ldapcivi extension (well, it's not really an extension, but we'll stick to that for now), as it offers more flexibility for users of any setup. I found the documentation lacking, so after some fiddling and email exchange with Xavier, I thought I'd share my learnings and general success at the end.

First and foremost you will need a node.js server, we have our site hosted with CiviHosting, which is a great service, but won't let you install anything the likes of a node.js server, so I turned to Amazon Web Services to help me out, it won't cost much for low usage and may even end up being free for the most part.

I went for the BitNami node.js option which was a one click set up really and meant I didn't have to do very much else. Once set up, you will need to open up port 1389 to allow the ldap port used by the underlying node.js code. This is fairly easy, go to your AWS instance control panel and under 'Network & Security', click 'Security Groups'.

Create a new Inbound rule, with a 'custom TCP rule', add 1389 as the port and hit the 'add rule' button, then the 'Apply Rule Changes' button.

Next, you will need to login to your AWS instance, this is done through SSH and you will need to download the key supplied to you in the 'Security Credentials' section of your main AWS account page and a command something along the lines of…

ssh -i ~/.ssh/aws.pem

Then you can run the install commands as supplied in the ldapcivi documentation

git clone
npm install
cp config/default.js config/yoursite.js
(Change to match your sites name)

The configuration file doesn't need too many changes and some of them will be up to your setup, the one area that confused me and what go things working for me were the 'settings.ldap.basedn' and 'settings.ldap.SUFFIX' settings, which I set both as "dc=greenrenters, dc=org", representing ''.

Then finally start the node.js server and service with "node server.js yoursite" (To match the above)

The ldapcivi documentation mentions that using Thunderbird initially is a good starting point and this is in some ways true, however I found to make it most useful, turn on LDAP debugging so you can see what was going on. You do this by following the instructions here, but change NSPR_LOG_MODULES=IMAP:5 to NSPR_LOG_MODULES=LDAP:5.

To get the Thunderbird address book to recognise the new LDAP server settings I used the following in the new address book settings:

Name - Up to you
Hostname - AWS server name
Base DN - dc=greenrenters, dc=org
Port - 1389
Bind DN - cn=root,dc=greenrenters,dc=org

I wanted to access the server through Mac Address Book / Contacts, here's the settings I used in the new account panel there:

Name - Up to you
Server - AWS server name
Port - 1389
Search Base - dc=greenrenters, dc=org
Scope - Subtree
Authentication - Simple
User name - cn=root,dc=greenrenters,dc=org
Password - As set in the config file on your node.js server

It's worth mentioning that with the current implementation of the civildap code it will just search contacts based on an input string, that's about it for now, if you want to see more functionality then chip in some contributions!


Would be great if you could improve and clarify the documentation. Pull Requests welcome ;)

While i'm at it: I got a ldap server configured and ready to use by your civicrm to avoid you going through Chris issuses. Would it be something you're interested by?


For instance, Drupal has LDAP and integration with views which would allow for various lists not just a single list.  Just some prelim thoughts.

It does?

Any guidance on this? Also, bear in mind the requirement for needing to work on shared hosting, do you need to install extra packages on the Drupal site?

drupal has a ldap client, not an ldap server so wouldn't work

Drupal can be configured to write to the LDAP server, given the correct LDAP rights.  The Drupal LDAP plugins have multiple configuration fields specifically for such a purpose.  Unfortunately, it does not seem to be a clean or easy setup.  I recall successfully writing to the LDAP from Drupal for a basic edit.  However, I was unsuccessful in new account creation, mainly because I did not have the correct LDAP mappings and needed to move on to other issues.  It is my understanding that most LDAP clients have edit capabilities, however permissions to edit a field must be explicitly given as all edits are denied by default.  The other problem I was facing was how to use the CiviCRM permissions, passed through Drupal to the LDAP config.  This looks to be even more difficult when looking at WordPress.

I thought the LDAP client would allow for two-way transactions. Guess the client only goes one way? From LDAP server to client but not the other way around?  Sorry to confuse the problem.

outlook/thunderbird have a ldap client integrated, but it only does read, not modify the contacts.

the ldap server I developped only implement read as well, but provided a client that does both read and write to test, would be easy to extended