Page tree
Skip to end of metadata
Go to start of metadata

This documentation is out of date

Please refer to the latest documentation on Understanding User Management in Confluence and Connecting to an LDAP Directory.

I am using Confluence version 2.2.x or later - how do I integrate with LDAP?

Please use this document.

I am using Confluence version 2.1.x - how do I integrate with LDAP?

Many improvements have been made in Confluence 2.2 to resolve the common issues people were facing with LDAP integration in 2.1. As such, we strongly recommend that you upgrade to Confluence 2.2 before proceeding with integrating your Confluence instance with LDAP.

Otherwise, please use this document.

Documentation index


  1. This additional information is very helpful. Running the ldapsearch ahead of time helps set things up properly. I also use JXplorer to help browse the directory.
    I think the 0.1_4 package has a few problems.
    1) Seems the 0.1_4 package is missing some stuff
    error: testIsMember(com.atlassian.user.impl.ldap.LDAPIntegrationTest): java.lang.ClassNotFoundException: com.atlassian.user.impl.ldap.searc
    h.LDAPStaticGroupAdaptor / junit.framework.TestFailure
    2) user.bat needs to reference 0.1_4.jar
    3) minor - comment says "Please check test.log" but it is tests.log

  2. Bob,

    Thanks for the feedback. JXplorer is a great tool, yes. (smile) Here are some responses to your comments.

    1) Well, the correct location of LDAPStaticGroupAdaptor is com.atlassian.user.impl.ldap.adaptor.LDAPStaticGroupAdaptor . If in doubt look inside the contents of the atlassian-user.jar :

    jar tvf atlassian-user-0.1_4.jar | grep LDAPStaticGroupAdaptor
    5053 Thu Jul 28 12:29:36 EST 2005 com/atlassian/user/impl/ldap/adaptor/LDAPStaticGroupAdaptor.class

    What does your file say? Are you re-using one from an earlier version of atl-user? The adaptor classes were refactored at some stage. Apologies about the change: next time I'll send out maintain a public list if the configuration alters. It's to be expected from beta code, though.

    The ldapGroupAdaptorClassName property should read:


    2) Yes, I'll fix the .bat file on Monday. Anyone else encountering this problem should open the .bat file and replace

    atlassian-user-0.1_3.jar with atlassian-user-0.1_4.jar .

    3) Yes, to be consistent the closing messages on stdout should specify tests.log and not test.log

    I'll upload an atlassan-user-0.1_4a.jar on Monday fixing these problems.

    Please let me know if you have further feedback. It is obviously very important to have our early adopters reach 100% success with the integration test.


    1. For 1) yes, I used old one. Copied over my data into new one and it worked fine. The "prompt" support on the test was very convenient. Finished the test and will send my results.

  3. Will it be possible to reference 2 different LDAP instances? For instance, we might have an internal LDAP and a different one for external customers. Also, can you give us an update on current plans for when this could be available? Thanks.

    1. Hi Bob,

      Yes, it will be possible to delegate user & group manager to multiple back-ends. Two LDAP systems will be fine.

      Atl User should be in Confluence for 1.6 DR1. I can't really give a timeline for it being incorporated within JIRA but we are aiming for a similar timeframe. Some time in the next two months, hopefully.


  4. Two points of interest and two questions:

    POI #1: The project for which I am looking at LDAP integration will most likely use static groups. This is because (to the best of my knowledge) there is not a standard objectClass with a memberOf attribute. One would have to write one's own objectClass, as you hint at in the Confluence LDAP Documentation Index section above. The standard groupOfNames class is used more in the static group model. Since we will most likely be using a plain LDAP server like OpenLDAP, rather than a commercial user directory like MS Active Directory or Sun's Directory Server (both of which have extended the standard schemas to handle dynamic groups), the static approach is more straightforward.

    (Let me say now that I am still very new to LDAP research and design, so if anyone wishes to correct anything I have said, please do!)

    POI #2: I found that I could run the standalone test framework against MS Active Directory using either the static or the dynamic group adaptor. For dynamic, I set the groupNameAttribute to memberOf (an attribute in the User object). For static, I set it to member (an attribute in the group object). Handy to be able to do it both ways, and a testament to the flexibility of your design. I have not verified, but I presume the groupSearchFilter can take a compound statement of the form (&(objectClass=group)(groupType=2)) so that it only finds organizational groups and not security groups? Which leads to my first question...

    Question #1: Are you intending the group relationship to find organizational groups or access privileges groups (i.e. "roles" as defined in the Sun document you reference)? I presume it is organizational groups, but want to make sure since things like Active Directory combine the two concepts and you have to look at the "groupType" attribute of the group to see if it's a security or organizational (distribution, as they call it) group.

    Question #2: A quick test with the framework showed that you do not support groups within groups, correct? That is, recognizing that a user is in both groupA and groupB if the user is a member of groupA and groupA is a member of groupB? I believe it would be straightforward to support in the static case (just searching for the DN of groupA in the groupNameAttribute of other groups), and could be done in the dynamic case if you made the assumption that the groupNameAttribute is the same in group objects as it is in user objects.

    The second point is more of academic interest at this time. I can't say that it's a requirement at this time.

    1. Hi Eric,

      Thanks for your comments and interest. It's interesting to hear about specific Active Directory requirements, most of the time we have to consider generic scenarios. It's also really positive feedback to hear about your tests.

      How many users were you running the tests with? Did they perform in a decent time?

      Answer #1 - The meaning of the groupType is in Active Directory has no consequence on the meaning of the group in JIRA and Confluence.

      If the mappings mean that the groups can be found, they will be used without respect to whether they are an AD 'role' or organizational group. It's up to you to define whether or not JIRA or Confluence can 'see' the groups, in the mappings. Yes, you can use a compound group search filter.

      Answer #2 - Yes, that's right. I knew someone was going to ask for this, at some stage, but we don't support nested groups just yet! And, again, as you say, it is probably straight forward to meet this need but we are just hoping to cross the finish line right now with the existing model. The finish line would be JIRA and Confluence both using Atlassian User and people reporting some success with LDAP integration and repository delegations.

      Let me know if you have any further questions.


      1. I've dipped my toe (and foot) into the LDAP integration and it's working (almost) like a charm - in an organization with 6000 user objects, probably 12000 machine objects, and who knows how many groups (several thousand at least), Confluence has done amazingly well at parsing out permissions.

        As you might imagine - the organization has 80 offices, four regions, eight or nine lines of business - organizational units and hierarchy are a mess. There isn't any group that everyone belongs to ... so hierarchical groups would be a big bonus for our usability. Hopefully this "straight forward" (not necessarily easy, I'm sure) enhancement would do wonders for administration in this organization.

  5. I only tested against a very small testing AD server - just a couple of users. Performance was fine.

  6. Nick, I am trying to get back to this now and have a questions:

    1. My current installation delegates user management to Jira. With this support being in Confluence 2.x (or the beta), can I continue to delegate some users to Jira using their existing Jira account?
    2. What configuration do you recommend for Confluence once this support is implemented before Jira support becomes available?

    I am trying to figure out how and when to go from where I am today to use this support in both Confluence and Jira. Thanks.

    1. Bob,

      I'll answer your questions in order.

      1. My current installation delegates user management to Jira. With this support being in Confluence 2.x (or the beta), can I continue to delegate some users to Jira using their existing Jira account?

      Yes, you can. Atlassian User can wrap around OSUser, if you want to use an existing OSUser installation. You would simply add an OSUser delegation in the delegation chain. So long as your osuser.xml file makes sense, it won't matter where the users come from - it could be JIRA or anywhere else. Obviously, you will need to have the typical Confluence groups set up in the osuser layer.

      I'll create a document describing how to do this - . I imagine many people will ask this question, further down the line.

      2. What configuration do you recommend for Confluence once this support is implemented before Jira support becomes available?

      I would recommend the simplest configuration as a first step, namely configuring Confluence's Atlassian User layer to defer everything to the OSUser layer in JIRA. Once you have transitioned that to production, I'd go through another testing cycle to introduce other repositories (LDAP, other Confluence installations, etc.) to the Atlassian User delegation, if you wanted that.

      Right now I'm working on Confluence 'Leichhardt', which will emerge as a DR of some form, post 2.0 . We will have to answer these questions for this release, so you will not be taken by surprise.

      If you would like, we can make available a test version of Confluence (RC2 or 2.0), running Atlassian User, and fulfilling the role of delegating to OSUser in JIRA. It won't be this week though.


      1. Nick, thanks. That is clear and helpful. So, I take it that the current version you have out doesn't support the delegation to Jira. That is ok, I can work around that for now.

        1. Hi Bob,

          The current version should do it, it's just a matter of knowing how to write the atlassianUserContext.xml up properly. Having said that, it would be better if you waited until we've documented it. I say this mainly because we're not ready to support experimental efforts with Atlassian User and Confluence.

          I wouldn't use the current version as anything more than a first impression.

          I've released another version since then and am now working on getting a further version out in the next few days. It would be worth waiting for that release to form a better impression of the base functionality.

          If you would like to discuss rolling something out, we can do so in the first release post 2.0 . I can help you plan what you're doing via email, if you like.


  7. All,

    I have a use case that I am not sure if it is addressed here. I have recently implemented an authorisation module against our ActiveDirectory, which has 20,000+ users around the world in it. The baseUserNamespace of which changes quite dramatically depending on what part of the company they are in. Our organisation contains several different corporations, each with their own URL and therefore baseUserNamespace. We want to be able to include users from different parts of the organisation around the world, and so in my module, the equivalent property is allowed to be multivalued space delimited (eg. 'dn=combined,dn=com,dn=au dn=combined,dn=co,dn=uk dn=combined,dn=com'). Just wondering if AUser allows this?


    1. Hi Jed,

      Atlassian User supports delegation - in other words, you can keep adding repositories as to a tree structure. Each repository (node) in the tree has a baseUserNameSpace, etc.. In your case you would have as many nodes as you have baseUserNameSpaces. The application would still pick them up.

      The downside to this approach is that you increase the number of roundtrips on the network to the same system, for each request. This might not be an issue, depending on how you plan your delegation and your network capabilities.

      Atlassian User takes the first result it finds in the delegation - e.g. 'get user Fred' will begin a traversal of the tree and that returns the first User with a username of 'fred', ignoring the rest of the tree. You could configure your delegation so that the most frequently accessed repositories were first in the delegation chain.


      1. Hi Nick,

        That is entirely adequate for our needs, you have to do multiple LDAP searches anyway due to the nature of the API unless you want to specify a very broad search at the LDAP (we don't). Multiple chained repositories means there is a little duplication in the config, not a huge price to pay - and more flexible anyway. Thanks for the quick response Nick.

        - jed.

  8. Hi Nick, et al.

    We are very interested in LDAP/Active Directory integration with Jira and Confluence. We are also interested in allowing these apps, via Atlassian User, to have write access to our LDAP, too, so that users can self-register without our having to manually intervene or write a bunch of scripts.

    Couple questions:

    1. Above, you mention that read-only access is the priority, but is write access still in the works?
    2. Do you have any ideas on how we would migrate our existing user accounts from Jira/Confluence to LDAP once LDAP integration is available? For instance, what will happen to the associations between users and the pages/issues they created? We'd like to switch to LDAP but maintain those associations. Will this be possible?

    Hope this is the right venue for these questions. I realize they're a little broader than the ones above. Thanks in advance.

    1. Hi,

      To answer your questions in turn.

      1. Above, you mention that read-only access is the priority, but is write access still in the works?

      We are not currently planning to add it. We haven't decided not to do it; you're actually the first customer to ask for it. (smile)

      Are you interested in this for both products? We can follow the usual process of creating an issue for write access on LDAP and let people vote on it. On the other hand, you can also email us directly to discuss it if it is a vital issue for your org..

      2. Do you have any ideas on how we would migrate our existing user accounts from Jira/Confluence to LDAP once LDAP integration is available? For instance, what will happen to the associations between users and the pages/issues they created? We'd like to switch to LDAP but maintain those associations. Will this be possible?

      We will write some sort of tool to enable the removal of duplicated users between the db and LDAP. We would also specify an excludes clause, e.g. 'remove each user in the db if it is also in LDAP, except for users on this list'.

      Regarding the second part of this question, I can't speak for JIRA just yet but in Confluence we store the association based on the username. So long as the username can be located at an application level, everything will work.

      As said before, it's risky to guarantee functionality before it arrives but your requirement will be fairly common and we want to meet it.

      Let me know if you have any further questions or commments.


      1. I recently took over for a system admin that implemented confluence 2.1.3. I recently upgraded to 2.2.2 and tried the LDAP according to steps provided on this website. I found that it duplciated all my users AND groups. 

        1. Where can I find the file where the users are stored??
        2. How can I remove the duplicate users, without having to start from the beginning?? 
        3. Is is possible to revert back to osuser authentication??


  9. Hi Nick,
    A very happy new year to you and the team.  We plan to install both Jira and Confluence tomorrow in our organization, to run it for a month as evaluation and allow users to play with it (and hopefully do something useful).  I am very interested in being able to integrate these products with our Active Directory.  From the discussion here, there were a number of requests ranging from a SSO approach to delegating password authentication to the Active Directory.

    Just so I am on the same page:
    1. Is it correct that we can bulk-import users from Active Directory into JIRA and Confluence?
    2. Ditto for groups?
    3. After this, users will log in with their AD name and password, and Confluence/JIRA will validate the password against Active Directory?

    Let me know - our entire rollout model depends on these answers.


    1. Hi Sanjeev,

      I apologise about it taking us so long to reply to you. I was away on holidays and the Confluence Support team weren't aware they should watch this space.

      To answer your questions in order:

      1. Is it correct that we can bulk-import users from Active Directory into JIRA and Confluence?

      This is possible for Confluence (which now has Atlassian User) but not for JIRA. The idea of importing users or groups, however, is perhaps less preferable to reading from Active Directory in real-time, i.e. the users and groups remain in LDAP but Confluence may call upon LDAP whenever it needs to find a user or group.

      2. Ditto for groups?

      3. After this, users will log in with their AD name and password, and Confluence/JIRA will validate the password against Active Directory?

      Not after the import, after the integration between Confluence and Active Directory, done via Atlassian User.

      Let me know if you have any further questions.


  10. Hi there. Same as above post, we are also considering Confluence, today/tomorow I will install Confluence for all users to evaluate. I have basically the same questions as the above post, related to Active Directory. Update on these questions is highly sought after.


    1. Hi Mircea,

      Again, as for Sanjeev in the above, we apologise for taking so long about getting back to you.

      Let me know if you require more information.


  11. Nick,

    Would it be possible to get a version of the atlasianUserContext.xml file posted that is configured to talk to two seperate ldap sources?  Would this be the same configuration for pulling users from two seperate branches on the same ldap connection?  We cannot search from the root down, and we must specify two distinct branches for groups.  I have been unable to get it configured properly.  So far, I have been successful at getting Siteminder integration which points to our LDAP directory.  I have also gotten group membership to link up to our AD forest.  We need AD integration for AD HOC users, and we want to use it to be able to distribute group management and user creation to the owners of spaces.

    1. This is a very complex configuration given the version of Atlassian-User bundled with latest stable build of Confluence. We are in the process of upgrading Confluence to use Polis (the new opensource name for the Atlassian-User project). Polis will feature significantly easier configuration.

      We recommend holding the configuration of the second repository until such a version is released.

      You can track our progress on this issue by watching this ticket:


  12. In our company, we use LDAP for authentication (and basic profile info), but not for any group management. Can I configure Atlassian-User to authenticate against LDAP but manage groups internally to Confluence?

    1. I'd like to do this as well.

  13. Is it possible to have our AD password on the atlassianUserContext.xml file hidden. I have users with access to this directory and don't want them to be able to looks at this file and see the AD password.

  14. Just wanted to weigh in with my hope that the Atlassian team is continuing to work on LDAP integration with Confluence and Jira.  We have migrated our chat system over to Wildfire with LDAP, and I'm happy with that (but must say that Openldap is very poorly documented, it took forever to get the security stuff right, and so my sympathies go to you about this).

    We would be an even more enthusiastic customer (and we are a paying customer), once you have created a system that allows any LDAP user to "invisibly" register with either JIRA or Confluence.

    Eagerly waiting.  It looks like this has been bubbling around for 3 years.  Any chance you can work on it?  I tried tracking the ticket for CONF-5581 and it doesn't look like much has happened?  The JIRA variant has a huge number of votes and watchers. 

  15. Because our Network OU's are divided up for site we have multiple OU's that need to be queried so that we can integrate LDAP for groups and users.
    Is it possible to do this with the atlassian-user.xml file or what would the workaround be?

    1. We have the same thing. Our tree has a tree of

      dc main
      dc sub
      ou HQ
      ou Mkt
      ou Sub-Mkt
      Users listed here
      ou Users
      Users listed here as well

      As you can see they are at different points in the LDAP tree. I cant seem to get the baseUserNamespace key written in a way that Confluence likes. One would think that
      <baseUserNamespace>OU=HQ,DC=main,DC=sub</baseUserNamespace> would work without specifying a searchalldepths key specified so it spiders down the path to find the users but no dice there.

      We can get the people in the ou Users into Confluence with this key:
      But have not had any luck getting the Sub-Mkt people in yet...

      1. The solution was to change this line to:

        the above layout wasn't too clear, this is what ours looks like

        dc main
        dc sub
        >>ou HQ
        >>ou Mkt
        >>ou Sub-Mkt
        >>>>Users listed here
        >>ou Users
        >>>>Users listed here as well

  16. Mik

    I have successfully hooked up LDAP authentication,
    but I want to disable local internal Confluence users,
    i.e. just run the LDAP credential provider, but not then failover
    to the local CachingCredentialsProvider if the LDAP fails.

    The process for new users registration would work like this:

    • new LDAP user creates account with LDAP username,
      given password is stored but ignored
      and they can only login with their LDAP password
    • new hacker creates account with non-LDAP username and password,
      but this does not authenticate against LDAP
      so they cannot login

    I realize that Confluence must have the local store enabled to keep the
    account username and profile, i.e. if I remove the CachingCredentialsProvider
    from the osuser.xml then the LDAP look-up does not work.

    Do I have to write a new authenticator that only tries the first CredentialProvider ?


  17. For anyone trying to troubleshoot LDAP issues, I highly recommend that you go vote for this issue regarding the lack of error messages:


  18. Hello out there...I've gotten a sucessful LDAP connection, but when i place a group level permission in global or a space they cannot access the space...only after adding the individual user can they browse a particular space. Any ideas what is wrong?

    Im a total n00b to confluence, jira, velocity the whole im hoping for some helpwhile i learn all of this.