Add LDAP Integration

I too am interested in a authentication-only configuration for Confluence 2.23+. I had zero problems with LDAP authentication for JIRA 3.62. How should I diverge from this procedure to get LDAP authentication only for Confluence?

I am currently evaluating 2.2.6a.  I was able to get Confluence authenticating off a Windows 2003 Active Directory at the group level within a couple hours.  Based on what I have seen with the LDAP integration, I trust it enough to take into production. 

I am new to Confluence, so some of that time was reading through the users guide and administration guides. 

This is a bit more difficult than other commerical software (such as those from Microsoft), but much better than open source applications.

I am not sure if this guide mentions it, but the log file can help you with this process.  Check <install folder>\logs\atlassian-confluence.log

You will see messages like this if Confluence can't connect to the LDAP server:

ERROR [bucket.user.DefaultUserAccessor] hasMembership javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece

A key for me to get this working was this setting.  If Confluence can't login to Active Directory, you will not get anywhere.

   <securityPrincipal>cn=<username>,cn=users,dc=<domain>,dc=<domainExtension></securityPrincipal>

Example with username = Administrator, active directory domain = test.local.

   <securityPrincipal>cn=Administrator,cn=users,dc=test,dc=local</securityPrincipal>

Not seeing atlassian-confluence.log anywhere on hosting server.  Wow, this is very difficult, myself and another experienced admin have spent almost an entire day on ssl and ldap integration, all wasted time.  I want to use this product, but feel as if I am doing alot of work for a product we will be paying quite a bit of $$ for.  Almost feels like pure open source.  Atleast just the ssl and ldap parts.  Other parts are smooth.

Ok, I finally got it working.  It was my fault, I missed a detail on the user and group repository.  I left out a dc=.  For example I had ou=people,dc=domaincontrollername,dc=edu when it should have been ou=people,dc=domaincontrollername,dc=parentlevel,dc=edu.

 Just be sure to go over the config with a FINE TOOTH COMB before you give up!!!!!

Sorry for blaming confluence, it was my problem. 

In my case the problem with configuration was in usernameAttribute - I had to replace cn with uid. <usernameAttribute>uid</usernameAttribute>.

In original file it maps userName to  cn which was in my case FirstName+LastName, not simple uid.

This information may help if you are new to looking at code.  Just know that these marks in the file <!-  -> are commenting out what lies between.  For example when this file full of code is run:

<!--
execute, blah blah blah
-->
execute blah

Only execute blah is actually run.  Look for this and make sure your entire LDAP configuration is not commented out.
FYI

Just wanted to offer this information, it may help someone.  I did LDAP integration and the groups the user belongs to do not reside as a "user attribute" this membership information only resided within the security group attributes, ie each group had a bunch of "uniquemember" fields listing the memebers.  Anyway in the instructions this line below sort of made me think to look at the user attributes for this field

Just any FYI that this attribute could also reside within the group attribute.  Or Active Directory environment is the opposite, the user object does list the groups that the user is a member of.  Good luck. 

Is it possible to map other attributes of a user in LDAP into Confluence (for example, homePhone, mobile, postalAddress, etc) for use in user profiles?

Ok, I started with Confluence 2.2.6, and was having no luck getting it to sync with our AD setup (Windows 2003). I upgraded to 2.2.9, and still had no luck. However, I was finally able to get it integrated. I found that with Active Directory in atlassian-user.xml you need to set your host as the IP address or your top level AD domain controller. The other thing is that the securityPrincipal attribute needs to be set to <user>@<domain>.<domain extension>, or test@thisisnotarealdomain.com. This is in contrast to CN=<fullname>,OU=<orginizationunit>,DC=<domain>,DC=<domainextension>

 The other thing, and this could be specific to just our setup, but we have groups per branch office, and not in the Users OU. To get all groups (and users for that matter) we had to set the baseUserNamespace attribute to DC=<domain>,DC=<domain extension> and the baseGroupNamespace attribute to the same.

Finally, make sure that if you provide a dedicated user for your LDAP integration involving an AD setup, you set the password to never expire.

Once I figured it out, it's easy, it's just getting that first step.

For others who are doing LDAP integration VIA Active directory, this particular entry works in my environment (where "XXXXXX" is replaced by a working password):

<ldap key="ldapRepository" name="IRAD LDAP" cache="true">
			<host>10.35.24.59</host>
			<port>389</port>
			<securityPrincipal>cn=Administrator,cn=Users,dc=irad,dc=net</securityPrincipal>
			<securityCredential>XXXXXX</securityCredential>
			<securityProtocol>plain</securityProtocol>
			<securityAuthentication>simple</securityAuthentication>

			<baseContext>ou=IRAD OU,dc=irad,dc=net</baseContext>
			<baseUserNamespace>ou=IRAD OU,dc=irad,dc=net</baseUserNamespace>
			<baseGroupNamespace>ou=IRAD OU,dc=irad,dc=net</baseGroupNamespace>

			<usernameAttribute>sAMAccountName</usernameAttribute>
			<userSearchFilter>(objectClass=user)</userSearchFilter>
			<firstnameAttribute>givenname</firstnameAttribute>
			<surnameAttribute>sn</surnameAttribute>
			<emailAttribute>mail</emailAttribute>
			<groupnameAttribute>cn</groupnameAttribute>
			<groupSearchFilter>(objectClass=group)</groupSearchFilter>
			<membershipAttribute>member</membershipAttribute>
			<userSearchAllDepths>true</userSearchAllDepths>
			<groupSearchAllDepths>true</groupSearchAllDepths>
		</ldap>

		<hibernate name="Hibernate Repository" key="hibernateRepository"  description="Hibernate Repository" />

I had the "already exists in OSUser Repository" error, and eventually found this which was quite an interesting read

Once we import all our users from LDAP, how do we hide those we don't want using the wiki? We use Open Directory and it contains some administrative accounts that I don't want to look at in the wiki's People Directory.

FYI, this document refers to the LDAP Dynamic Groups Plugin, which I don't think will work against Confluence 2.6.  I've set it up myself and it seems to be trying to make calls to an older API, giving a NoClassDefFound exception.  I would be a good idea to note this for folks who are trying to set up 2.6.  It's a very appealing plugin and I'd like to use it if I can.

Hi!

We need some help!

We are trying to integrate Confluence 2.7.1 with our Active Directory (under Windows 2003) but it is impossible for us. Our goal would be that only users defined in an Active Directory group called "Confluence" can log-in in Confluence server. Here are the steps we have followed "to do" the integration:

1.- We have defined a new group called "Confluence" in Active Directory under the "Users" section.

2.- We have "configurated" users in order to they can belong to this new group: we have defined that users "Daniel" and "Helen" belong to "Confluence" group. In other way, user "Peter" does not belong to this group. This is because we would like to use it in order to test (in the future) that only users which belong to "Confluence" group will able to log-in in Confluence server. All users are under the "Users" section.

3.- We have installed MySQL 5.0 in our Windows 2003 server

4.- We have installed and integrated Confluence 2.7.1 with MySQL in our Windows 2003 server (we have an "all-in-one" server ).

5.- We have setup Confluence without LDAP/AD integration: this means that in Confluence, we have defined only one user (the super-user) which username is "admconfluence" and we have defined a test-space called "Test". Of course, user "admconfluence" does not exist in our Active Directory server and also, we don't have defined in Active Directory any gro