Confluence 3.5 LDAP authentication
Asked by David Dube:

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


Answers:
author: Adam Laskowski
body: 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](http://confluence.atlassian.com/display/DOC/Confluence+3.5+Upgrade+Notes#Confluence35UpgradeNotes-ForCustomersusingLDAPforUserManagement) 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](http://confluence.atlassian.com/display/CONF35/Connecting+to+an+LDAP+Directory) post upgrade.

Adam


author: Adam Laskowski
body: 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).


author: AlexH
body: 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.


author: AlexH
body: 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.