How to make Atlassian Confluence talk (again) to IBM Lotus Domino

| No comment | 0 TrackBacks

Atlassian Confluence used to play nicely with IBM Lotus Domino, until Confluence version 3.5.3 came out with an embedded Crowd stack. The issue is that the default structure of a Lotus directory is mainly flat for groups, which are placed at the root level and do not share a common base DN with users (actually they may not have a base DN at all).

A typical Lotus directory entry as seen through Domino would look like this for a user and a group respectively:

  • User record: dn: CN=John Doe,OU=Department,O=Company
  • Group record: dn: CN=Group Name

This became an issue when Crowd landed in Confluence, because Crowd not only mandates a non empty base DN, but also requires the same base DN for both users and groups, making Confluence basically impossible to use with a Lotus Domino LDAP server since April 2011. I raised this double bug regression in May 2011 and have been waiting for its resolution ever since (along with 3500 users for that single installation, and then some).

If you are in a similar situation, rejoice, I found a workaround! While I'm still hopeful that Atlassian will finally resolve this regression, this should help you upgrade to the most recent version of Confluence, which has gone a long way since the 3.4 branch. Warning: this is a hack, provided without any guarantee, you are free to use it at your own risk. If you need full support from Atlassian, I suggest that you vote for the aforementioned bug report and wait until it is resolved (but don't hold your breath).

The trick is to add a rewrite/remap layer between Confluence and Domino using the slapo-rwm overlay combined with the OpenLDAP slapd proxy backend. You can then perform a “suffix massage” with a fake base DN, with slapo-rwm removing it from Confluence requests and adding it back in Domino responses. Assuming that "O=Confluence" is set as the Base DN in the Confluence LDAP user directory configuration, the example records above will now look like this for Confluence:

  • User record: dn: CN=John Doe,OU=Department,O=Company,O=Confluence
  • Group record: dn: CN=Group Name,O=Confluence

For this to work, you will need to:

1. Install OpenLDAP on a server (for this example I'll assume it's on the same server as Confluence, replace “localhost” with the server domain name otherwise).

2. Create a configuration file for slapd in /etc/ldap/slapd.conf. Here's a minimal one (replace parameters as needed, YMMV):

# This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options.

# Global Directives:

# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/

# List of arguments that were passed to the server
argsfile /var/run/slapd/slapd.args

# Read slapd.conf(5) for possible values
loglevel none

# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_ldap
moduleload rwm

# The maximum number of entries that is returned for a search operation
sizelimit unlimited
timelimit unlimited

# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1

# Proxy backend configuration
database ldap
suffix ""
rootdn ""
uri "ldap://yourldapserverFQDN:389"
acl-bind bindmethod=simple binddn="replace with your bind DN" credentials="password"

# You may want more restrictive access and limits
access to * by * read
limits * time=unlimited

# Suffix massage for Confluence
overlay rwm
rwm-suffixmassage "o=Confluence" ""

3. Launch slapd (the -u and -g parameters set the user and group for the daemon, -4 forces it to run with IPv4 only, -f points it to your configuration file):

sudo slapd -4 -h ldap:// -u openldap -g openldap -f /etc/ldap/slapd.conf

(Or rather set it up to launch at boot time.)

4. Add or configure an OpenLDAP user directory on Confluence, using "o=Confluence" as the Base DN (or whatever you configured in the rwm-suffixmassage directive above) and point it at the proxy slapd server.

Et voilà, with a common (though useless) base DN for both users and groups, both Confluence and your users are happy again :-).

Some business thoughts to Atlassian:

  • This issue isn't just limited to Lotus Domino.
  • There are a lot of Lotus Notes users out there that would be very happy with Confluence. But they can't use it because you made it hard for them to switch. Don't you want their business?
  • Saying that you don't have a Domino server for testing isn't an excuse. Please install one. Or ask your own customers (or experts ;-) for help. Also, the circular reference between this IBM Lotus Domino Integration page and the CWD-125 (Provide Lotus Domino Support) request to suggest that it works for some customers is quite weird.
  • Acknowledging a bug as a regression is great and appreciated. But not fixing it across two maintenance cycles means forcing a client to pay for the privilege of not being able to upgrade their Confluence instance. While touting in gory marketing details how fabulous the next versions are. (And compared to 3.4, they indeed are!) This is not a good illustration of your “Don't #@&! the customer” motto (which I've seen in the entrance of your Sydney office no later than last Friday).
  • Despite the above, your customer support team absolutely rocks. Special hat tip to Linh, Vincent, Mickael and whoever in development is working to get this bug fixed (you know who you are ;-).

No TrackBacks

TrackBack URL:

Leave a comment

N.B. by commenting, you accept the comments policy.

About this Entry

This page contains a single entry by François Nonnenmacher published on July 10, 2012 2:45 PM.

Twitter for Mac accessibility was the previous entry in this blog.

Find recent content on the main index or look in the archives to find all content.