This page last changed on Mar 20, 2007 by david.soul@atlassian.com.
Confluence can delegate user authentication to LDAP and use LDAP group memberships to set the user's Confluence access permissions. This guide is for both users enabling LDAP, and those upgrading their LDAP scheme to support group management. It applies to LDAP over HTTP and SSL/HTTPS:
Once the LDAP is enabled and LDAP users are using Confluence, you cannot revert back to local user management without those users being disabled. However, you can create new local users while using LDAP integration.
Who is this guide for?
To decide if this is the correct document for you, please answer these 3 questions:
- Do you want use keep using internal Confluence groups but have LDAP passwords for logins? If so, follow Adding LDAP Integration Authentication Only instead.
- Are you using Atlassian-User LDAP on Confluence 2.1.x? If so, follow the 2.1.x LDAP Upgrade Instructions instead.
- Are you using a version of Confluence older than 2.1? If you are using 2.0.x, follow OSUser LDAP integration instead. If it is older thant 2.0, you must upgrade Confluence.
Step 1 - Upgrade Confluence
Please check that you are running the latest version of Confluence. If not, we strongly recommend that you consider upgrading Confluence according to this guide. Confirm that you have upgraded successfully before trying to add LDAP to the new version.
Integration can only be setup by an administrator confident with running user queries against their LDAP directory. You should request assistance from your LDAP or Active Directory administrator for the following steps.
Step 3 - Check your LDAP server
Confirm this information about your LDAP server.
- Check your server LDAP version. Supported versions are v2 and v3. Supported LDAP servers include OpenLDAP, Microsoft Active Directory, Novell eDirectory, and any server that uses Java JNDI-LDAP mapping.
- Your LDAP or Active Directory server must support static groups. This means that the user DN's must be stored against a membership attribute inside an LDAP groups. An example of a static groups is shown below:
The membership attribute in this case is member, but this is not required. Note that the full DN's of John and Sally Smith are listed.
- You must not have LDAP groups called 'confluence-users' or 'confluence-administrators'.
- You must have at least one existing Confluence administrator who's username does not exist in the LDAP server.
Step 4 - Confluence user migration
The new Atlassian-User-LDAP-Integration depends on a new user managment component and requires you to migrate your current users even in the case of new installs. The following steps will guide you:
- You will need to find out your Confluence base URL. To check this from Confluence, go to Administration > General Configuration > Base Url. Record this for later in the process.
- You must create backups in order to rollback to the old version if the migration is unsuccessful. Make a backup of your:
- database
- Confluence home directory
- confluence/WEB-INF/classes/atlassian-user.xml (only if you have made changes)
- Download hibernate_osuser_atlassian-user.xml and rename to atlassian-user.xml and copy to your confluence/WEB-INF/classes directory (you can overwrite the one that's there)
- This step is only for users running Confluence 2.3.0. Right click on osuser2atluser.jsp and download it to the \confluence\admin subdirectory of your Confluence install. Overwrite the existing osuser2atluser.jsp file.
- Restart Confluence. Login as an Administrator, copy the address http://<BASEURL>/<contextpath>/admin/osuser2atluser.jsp and paste it into your browser's address bar. Edit the <BASEURL> to your actual base URL and <contextpath> to your context path (usually 'confluence') and follow the link.
- Click the link Begin migration. You will know the migration has been successful if you see this reported:
Migrating users ... Users migrated successfully!
Migrating propertyset data ... Propertyset data migrated successfully!
Migrating groups ... Groups migrated successfully\!
If you encounter errors, please create a support ticket at http://support.atlassian.com and attach your application server logs.
- Stop Confluence.
- Start up Confluence and check that you can login using the admin account you first set up when running through the Confluence Setup Wizard. If not, re-examine your steps and repeat from there.
- If you can't successfully login with this account, please check that the username of this account does not already exist in your LDAP server. If usernames are the same, Confluence recognises LDAP accounts over local Confluence accounts.
- Download ldap_hibernate_cache_atlassian-user.xml, rename it to atlassian-user.xml then copy to your <INSTALL>/confluence/WEB-INF/classes directory. It should overwrite the previous atlassian-user.xml.
- Follow Customising atlassian-user.xml
Step 6 - Grant access to LDAP users and groups
To grant Confluence access to an LDAP group:
- From Confluence, go to Administration > Global Permissions
- Click to Edit Permissions for Groups
- In the textbox to Grant Browse Permission, enter the name of an LDAP group that should have Confluence access. Click Add.
- Tick the Can Use box for the LDAP group. If the group is not found, it was not present in your LDAP server.
- For other LDAP groups that need access to Confluence, add them using the same method.
- Setup your Confluence page and space permissions for these LDAP groups.
Installation complete!
Troubleshooting Resources
Failing that, lodge a support request. Be sure to attach your atlassian-user.xml, Paddle logs and a zip of your Confluence logs.
I thought I would add a positive comment here. Just went into production on Confluence 2.2 using LDAP for user enrollment and authentication, mostly following the instructions here. It took a while and a number of support requests, patches, and workarounds to get things working for our purposes. Special thanks to Dave Loeng for his help. Still using Confluence defined groups for permissions for now until some group related problems get resolved.

Posted by bob.swift@lakeviewtech.com at May 12, 2006 16:51
|
I have been able to successfully import users and groups from our eDirectory LDAP server, however, ANY string (even an empty string) passed as a password will pass validation and allow a user to log in. Have others been having this problem? It seems as though as soon as a username is found in in the LDAP server, it is authenticated without checking against that user's password. We are using eDirectory with static groups with SSL authentication. No errors have been reported in the logs, so it seems as though this is "accepted" behavior by Confluence. I'm sure I probably have a setting incorrect somewhere and wanted to know if anybody else has encountered this problem and discovered a solution. I was able to find one message on the user mailing list with the same problem, though no reply to that message. Any help that could be offered would be greatly appreciated.

Posted by cstivers at May 22, 2006 15:23
|
This WAS a setting error on my part. While I was using "none" for the <securityAuthentication> property of my atlassian-user.xml, I mistakenly used "none" for the <authentication> property as well. Doing so simply skipped any authentication query made by Confluence. The page administrator can feel free to delete this comment as well as then one it is a response to, as this was a simple mistake on my part, and probably not something that will occur often for other users.

Posted by cstivers at May 22, 2006 17:39
|
Not clear for me. Can you provide information how I should configure Confluence + LDAP but without users Migration (use LDAP password only) ? I want see the same result as in JIRA configuration and as I can understand I don't need Mapping of LDAP Data Information Tree . We have about 1000 users in LDAP but Confluence should use 10 users only, as result Migration not needed. So, JIRA works ok with LDAP configuration and with 10 users, which are already added manually.
Thanks.

Posted by vitalijs at Jun 16, 2006 02:43
|
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?

Posted by lima at Jun 25, 2006 20:59
|
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>

Posted by grothwell at Jul 31, 2006 02:57
|
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.

Posted by chuman at Aug 03, 2006 01:25
|
The location of your Confluence log file will depend on your application server. The location he mentions is configured for Confluence Standalone only; the EAR/WAR edition logs to the application server's stdout.
If you're still having trouble with configuring LDAP, please raise a support ticket on http://support.atlassian.com. We'll be able to walk you through the installation process and diagnose the problems you've encountered.

Posted by mryall at Aug 03, 2006 01:44
|
Authentication-only LDAP integration is still available via OSUser in Confluence 2.2, but I don't really see why you would want that. In the old world of LDAP support in Confluence 2.1 and earlier, you only have one type of user and one type of group:
- User must exist in Confluence, password authenticated against LDAP.
- Group must exist in Confluence, and can only contain users that exist in Confluence.
The new LDAP configuration allows so much more:
- User can be a strictly Confluence user, password stored in Confluence.
- User can be an LDAP user, where both user details and password authentication are from LDAP.
- Group can be a strictly Confluence group, and contain any LDAP or Confluence users.
- Group can be an LDAP group, and contain LDAP users as configured in your LDAP server.
Confluence access can be granted to any of the above categories, without the extra step of creating a new user or group in Confluence. Once a user or group has Confluence access, it can be used in space permission and page restrictions, without worrying whether it is in LDAP or Confluence.
In the future, we're planning to support retrieval of arbitrary LDAP properties for users and displaying these on the profile page. Some LDAP servers support storage of user pictures, so this might also mean automatic profile icons. None of this will be possible if you stick with the old LDAP support.
There also seems to be a bit of a misunderstanding about the migration process. The migration is simply an internal database table migration, no data is copied to or from the LDAP server. At some point in the future we'll probably be migrating everyone to use the new database tables via an automatic upgrade task.

Posted by mryall at Aug 03, 2006 02:56
|
The location he mentions is configured for Confluence Standalone only; the EAR/WAR edition logs to the application server's stdout.
I have confluence installed in the location off the C drive as the instructions recommend. (c:\confluence2...\confluence) and backup going to (c:\confluence_backup_data). Could you point me to the log files in this setup. I don't understand the "stdout" term. Thank you.

Posted by chuman at Aug 03, 2006 08:19
|
I got you now, I am using Tomcat, I will look there. Thx

Posted by chuman at Aug 03, 2006 08:33
|
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.

Posted by chuman at Aug 03, 2006 14:01
|
Sorry for blasting the forum today. Is there any way to avoid a plaintext password in the confluence-user.xml folder for the securitycredential value? Thank you.

Posted by chuman at Aug 03, 2006 14:26
|
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.

Posted by daniel.veselka@i.cz at Aug 03, 2006 14:38
|
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

Posted by chuman at Aug 04, 2006 08:02
|
We have groups in different OU's but with identical names. Is there a way to configure the search filter or any other setting so that the Manage Groups administration page can differentiate between them?
Example groups:
cn=everyone,ou=cityA
cn=everyone,ou=cityB
Currently, we see only one group called everyone and the users listed within it are incomplete.

Posted by jwright at Aug 04, 2006 11:32
|
John, you may be able to get this to work by setting:
<groupnameAttribute>dn</groupnameAttribute>
But this isn't a configuration we have tested.

Posted by tom@atlassian.com at Aug 06, 2006 18:34
|
Thanks Tom. Using dn for the groupnameAttribute didn't help unfortunately. I also tried cn:dn: and other combinations but wasn't successful.
Most of our groups are unique so we're happy and well on our way for the time being. Perhaps groups with identical names can be addressed in a future release...
John

Posted by jwright at Aug 08, 2006 15:32
|
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
membershipAttribute |
atlassianGroupMemberOf |
This attribute should identify which groups the user belongs to. |
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.

Posted by chuman at Aug 10, 2006 21:10
|
Hi all,
a simple question. Actually, Confluence is used with built-in user management. Some users and pages were created.
We would like to integrate our LDAP without losing link between users and pages. Is the LDAP migration will preserve these links ? Is it possible to map exactly "built-in" users and LDAP users ?
Thanks

Posted by confluence@albertyorban.be at Aug 20, 2006 03:20
|
I found the detailed describing LDAP Auth Only vs. LDAP Group management as described in version 68 of Adding LDAP Integration To Confluence was quite useful.

Posted by aholtz at Aug 31, 2006 13:10
|
Does Confluence support multiple Directories on the same Confluence instance? We have several directories, A/D and eDirectory, which are currently disjointed and do not follow the same standards. Each user would then be authenticated against the respective Directory.
Thank you.

Posted by bmarjan@pershing.com at Sep 01, 2006 14:08
|
At present, no, but this is a feature we intend to add. We don't have a timescale for doing this yet.

Posted by tom@atlassian.com at Sep 05, 2006 20:40
|
When trying to do the migration in step 3/4.5 I kept getting an error about the osuserMigrationBean is not defined. I had to go into WEB-INF/classes/upgradeSubsystemContext.xml and uncomment the definition. This made the migration work correctly as stated. I'm using the latest 2.2.8 standalone version from the website.

Posted by scoggins at Sep 06, 2006 02:54
|
Once you have migrated the local users in 3/4.5 you'll need to comment out the osuserMigrationBean definition again. If you continue, there will be an exception as it tries to load it. So uncomment it, migrate, comment it out.

Posted by scoggins at Sep 06, 2006 05:58
|
On confluence 2.2.9 I got strange behavior with usernames which are existing in the local DB and the LDAP too.
1. As Admin I see this users twice.
2. They are just members the groups from the LDAP, and lost their local group memberships.
3. This is true for all users who are existing as local and as LDAP Users regardless if these users are member of an LDAP Group.
4. If I remove one user from an LDAP group this change has no effect to confluence. Confluence shows the user still as member of that group.
Is that normal behavior or do I miss something ?

Posted by d.oelkers@fh-wolfenbuettel.de at Sep 11, 2006 13:18
|
Hi Dirk,
You should not have users who exist in both LDAP and Confluence. In general, the LDAP users will take precedence, but this situation is not recommended.
1. Confluence does not currently support the same username existing in LDAP and Confluence. It considers them two distinct users for some purposes, and the same for others.
2. Because the LDAP user takes precedence, this LDAP user will not have any local membership. You will need to add the LDAP user to the local group again.
3. See 2.
4. Confluence caches LDAP search results to improve performance. It may take 15 minutes before changes to your LDAP server are reflected in Confluence.
Regards,
Matt

Posted by mryall at Sep 11, 2006 19:30
|
Hi,
i reverted back to local user managment from LDAP and i didnt have problems so far. So i dont understand the warning at the beginning of this document.
I just restored the old atlassian-user.xml file and it worked fine.

Posted by loetterle at Oct 04, 2006 05:40
|
I followed these instructions, everything seemed ok on the surface but I noticed that when searching for groups to add into global permissions, I can only find some (100) groups but I have many more at the same level in the same tree. I am still using the evaluation key, could this be why?

Posted by jcoates@icgcommerce.com at Oct 31, 2006 19:14
|
fyi Your link to the Customising atlassian-user.xml page does not work in Firefox 2. Works in IE6 just fine...

Posted by jguthrie at Nov 09, 2006 18:28
|
What does it do? It works for me in Firefox 2 on OS X

Posted by tom@atlassian.com at Nov 09, 2006 23:23
|
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?

Posted by ibanix at Dec 11, 2006 13:50
|
Hi Joshua,
Unfortunately Confluence does not support this feature. The only attributes that you can map to Confluence is available at:
http://confluence.atlassian.com/x/eUUC
In addition, there is an open feature request being tracked at CONF-5286. Feel free to cast your vote to increase its popularity and add yourself as a watcher for future updates.
Regards,
Mei

Posted by meiyan.chan@atlassian.com at Dec 11, 2006 23:15
|
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.

Posted by sjantzen@fairpoint.com at Dec 20, 2006 11:52
|
The instructions say:
{{... http://<BASEURL>/<contextpath>/admin/osuser2atluser.jsp }}and paste it into your browser's address bar. Edit the <BASEURL> to your actual base URL and <contextpath> to your context path (usually 'confluence') and follow the link.
But this does not work for me. I have 2.3.3 with the built in database. I have to enter:
http://<BASEURL>/admin/osuser2atluser.jsp
Note the lack of /<contextpath>/ which usually equals confluence. I tried again and again with /confluence/admin/ until I noted the correct URL in my browser's URL history.

Posted by jdavis at Mar 05, 2007 16:19
|
Would it be possible 2 migrate users to LDAP in 2 phases: migrate users in a first phase (authentication via LDAP only) and then migrate the groups in a second phase (Group Management in LDAP)?

Posted by bmarjan@pershing.com at Mar 20, 2007 16:02
|
|