Confluence User Directory, JIRA, and LDAP integration

[Mike Jansen]

OK, I'm running into a string of issues I'm trying to resolve and thought getting some feedback from the community would be a good thing :)

Our current setup:

LDAP server (ActiveDirectory) that hosts our domain logins. The kicker is that all this directory has is login name and password. It's not linked to our Exchange logins, etc. I work for a huge company and security policies are set overseas, so this isn't going to change.

The idea is for our internal company users to login with their domain (LDAP) user and external users have local JIRA/Confluence accounts.

JIRA 4.2.4 is configured with local users and LDAP password-only authentication with fallback to local password (for external users that don't have an LDAP account). All users are added manually and groups are managed manually in JIRA.

Confluence 3.4.9 is configured with LDAP user integration (not group integration) with fallback to local users for external users without an LDAP account. Because our LDAP doesn't have display name or email address, those fields are blank for all of our internal users (obviously yuck). We manually add users to confluence-users and confluence-administrators (and other) groups.

Our biggest goal is to be able to configure the Display Name and Email Address of our LDAP users in Confluence, since we don't have (and won't have) these values in LDAP.

So here's what I've tried so far.

I'm testing an upgrade of Confluence to 3.5.7. I originally tried to the new LDAP User Directoy, but it still leaves me without the ability to modify Display Name and Email Address locally.

So then I tried the Legacy JIRA User Directory. This solved the Display Name / Email Address problem, because it pulled those from JIRA. And all of our external users (not configured in LDAP) worked fine. However, the Legacy JIRA User Directory just pulls the local JIRA password into Confluence's Crowd junior tables, and obviously can't synchronize the LDAP passwords. I verified this by setting the local JIRA password on an account that normally gets the password authenticated via LDAP. I was able to login to Confluence with the local JIRA password for that user but not the LDAP password.

I'm beginning to think our only options are going to be either to 1) fix our LDAP directory to have all the information we need (ain't gonna happen) or 2) write a custom user directory plug-in that meshes LDAP and local.

Any thoughts?

Thanks,

Mike Jansen

[JamieA · Accepted solution]

Are you sure that this information is not in active directory? Or could it be that you just don't have permission to view certain attributes... Exchange needs a certain amount of information to work. If that information is not stored in AD where is it stored?

Alternatively... I have had a certain amount of success running my own openldap server for the atlassian tools, which is populated from the corporate ldap server. I configured pass-through authentication with SASL so users are authenticated against the corporate ldap, not mine. It's a hassle to set up but works nicely once done, and also allows you to use ldap groups (which generally you cannot do with ldap in a large corporate).

[Mike Jansen]

I am 100% sure it is not available in the Active Directory that contains our domain logins. It's a "security measure".

We may try our own LDAP server at some point. In the mean time, Tiago Comasseto of Atlassian Support gave me a solution: the Delegated LDAP User Directory which is basically what we do in JIRA (but it's called LDAP Password-only authentication). It meets our needs very well for the time being in that we validate the password against LDAP but the email/display name are in Confluence.

Mike

[Mike Jansen]

Thanks for the thoughts on using our own LDAP server; we may use that in the future.

Mike

[Mike Jansen]

I am 100% sure it is not available in the Active Directory that contains our domain logins. It's a "security measure".

We may try our own LDAP server at some point. In the mean time, Tiago Comasseto of Atlassian Support gave me a solution: the Delegated LDAP User Directory which is basically what we do in JIRA (but it's called LDAP Password-only authentication). It meets our needs very well for the time being in that we validate the password against LDAP but the email/display name are in Confluence.

Mike

[Julius Juurmaa]

I ran into a similar issue a while back. We have a Confluence 4 installation configured to use internal/LDAP authentication -- so users are authenticated against LDAP and local profiles are created.

Our LDAP server stores only the user's full name and a bunch of other things that hold no relevance for Confluence. E-mail addresses, for example, are not stored. I solved this problem by letting Confluence get the missing information from a "dummy" field. The LDAP server simply gives a blank result, which is then stored in Confluence. Job done.

However, the internal/LDAP authentication scheme also means that, on every subsequent login, user details are overwritten with values from the LDAP server. So, if a user changes his/her e-mail address in Confluence, it is overwritten with a blank value next time he/she logs in. I did a little digging; it appears that Confluence's internal Crowd has an attribute "crowd.delegated.directory.auto.update.user" which stops the overwriting. So I set it to false:

UPDATE `cwd_directory_attribute` SET `attribute_value`='false' WHERE `attribute_name`='crowd.delegated.directory.auto.update.user' AND `directory_id`='<your directory id>';

And now it works properly.