Confluence 3.5 LDAP authentication

I'm looking to upgrade from 3.4.X to 3.5.X which means I need to configure LDAP authentication.

Is the authentication via querries to/from the LDAP directory, or is confluence doing an LDAP bind (via a bind request) to check for a valid uid/pw combo?

The way I read some of the documentation in some places, it sounds like the PW is requested, and then compared by the application, as opposed to asking if the uid/pw combo exists.

Any insight is very much appreciated!

Dave

4 answers

Hi Dave!

An LDAP authentication from Confluence is in fact an LDAP bind as that user to verify that their credentials are correct. If the bind attempt comes back as valid, the user is authenticated without LDAP passing the password attribute back to Confluence. Confluence won't ever request a password and compare locally as it's insecure.

As for upgrading, be sure to read over the pertinent upgrade docs if you already have LDAP configured on your 3.4 instance. If you don't have LDAP integrated yet, follow the standard upgrade at the top of that doc and then you can integrate LDAP post upgrade.

Adam

LDAP integration in Confluence 3.5.x is handled via a mini-version of Atlassian's Crowd application. They refer to it as "embedded crowd."

It syncs (user-configurable) every 60 minutes with your AD/LDAP server and fetches all the information it needs to handle all user authentication tasks. This includes usernames and the password hash.

When users login the confluence application handles all the authentication details. The only time confluence talks to your AD/LDAP server is once every (user-configurable) 60 minutes during the syncronization step.

LDAP integration in Confluence 3.5.x is handled via a mini-version of Atlassian's Crowd application. They refer to it as "embedded crowd."

It syncs (user-configurable) every 60 minutes with your AD/LDAP server and fetches all the information needed to populate your list of users and their details.

I had understood this to mean it also grabbed the password hash and performed the authentication itself because I've noticed that even when the LDAP servers are down confluence is still able to successfully process logins, but if Adam & Atlassian say otherwise then I would believe them.

Confluence does grab a lot of user information from the database during sync in order to poulate the DB cache with user information, however, the password is an excluded attribute. The value in the database for all external users is stored as "nopass." 3.5+ still use a bind as was the case in 3.4 and earlier. We don't want to sync a password for any reason because the values are all sent as plaintext by from LDAP and any setup that wasn't running LDAPS would be vulnerable.

The reason that you're able to authenticate even when LDAP is down is either due to the user authetication caching that is stored in memory, or because the user had a valid session token in their cookie (JSESSIONID).

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Oct 24, 2018 in Confluence

Atlassian Research opportunity with Confluence templates

Do you use templates with Confluence? Take part in a remote 1-hr workshop. You'll receive USD $100 for your time!   We're looking for people to participate in a   remote 1-hr workshop...

1,522 views 25 14
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you