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
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
# List of arguments that were passed to the server
# Read slapd.conf(5) for possible values
# Where the dynamically loaded modules are stored
# The maximum number of entries that is returned for a search operation
# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
# Proxy backend configuration
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
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://127.0.0.1:389 -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 ;-).