Blog

Hey all,

Hope everyone had a happy 4th of July!

Some time ago, my colleague Hani Atalla had touched on some of the work that we at Function1 have been involved with in regards to Atlassian Confluence, WCI, and few other products. In my article here however, I'll share some of my experience with an aspect of user management that we had dealt with on that project. Historically, for this customer , the enterprise has had Active Directory (AD) for several years and was being used by their WCI implementation. Along the way, we had also began to deploy some Atlassian products for the customer such as Confluence, Jira, and Crowd. These products were deployed in such a way that we ended up with segmented user accounts in separate, local repositories/databases. Quickly realizing that this will eventually cause headaches for the users and for us to manage, we started to plan out a move towards a central user repository via a directory service. So we began by narrowing down the choices for a directory server from a list that included AD, Oracle Internet Directory, Apache Directory Server, and OpenLDAP. Choosing a directory server for the enterprise came down 2 factors for the scope of this project:

1. Atlassian Crowd needed to support it , as this product was our foundation for single-sign-on and user management.
2. Preserving the user information in the Confluence application, including user passwords.

While looking at OpenLDAP as a feasible option, we discovered the following "gotchas":

• Confluence uses a special "flavor" of SHA-512 for password encryption called Atlassian-SHA1 which is not directly supported by OpenLDAP
• Our Atlassian Crowd admin console did not have an option for Atlassian-SHA1 for password encryption when creating a directory.

But it turned out that there were available solutions to these 2 issues, so we decided to move forward with OpenLDAP. The latter issue regarding the Crowd console was handled by creating a custom Crowd plugin to have the Atlassian-SHA1 option (actually called "SHA512" in our solution below):

screenshot.60_0.png

And for the former issue dealing with OpenLDAP password encryption, we found the solution in the form of a custom OpenLDAP SHA2 module provided by Atlassian (Note: this SHA2 module includes support for SHA-512). Most of that Atlassian article was very informative and it helped us with building the OpenLDAP SHA2 module. Though, I had some additional notes that may help others:

1. When compiling the source on a new linux(Ubuntu) server, we ran into errors with missing C-language header files. This was resolved by installing 2 packages required for C-language development:

> sudo aptitude install libc6-dev
> sudo aptitude install libdb4.7-dev

2. Our OpenLDAP implementation used dynamic configuration, so we needed to use the steps below to configure the new SHA2 module. Documentation on dynamic configuration is rather scarce, so this was not as trivial for an OpenLDAP newbie.

(a) Create an LDIF file with the following contents:

dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /usr/lib/ldap
olcModuleLoad: slapd-sha2


(b) Then run the following command to apply that module:
> sudo ldapadd -Y EXTERNAL -H ldapi:/// -f .ldif

Once these two pieces were in place, we were able to successfully integrate Crowd and OpenLDAP and migrate the user accounts from Confluence. So to summarize, this was no easy integration between these two products, but they worked well together after applying some customization. If you have any further questions about these products or our setup, we'd be glad to help.

best,
-Vasanth