• We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      We use LDAP to authenticate from user data in Microsoft AD.

      Please see support.atlassian.com ticket (CSP-17940)

      Request:
      Implement paging for LDAP search requests, so that organizations with more than 1000 users can view all of their users in site administration (without adversely modifying ldap server parameters) and LDAP filters of moderate complexity can be supported. The LDAP paging control OID is 1.2.840.113556.1.4.319.

            [CONFSERVER-12219] Implement paging for LDAP search requests

            This is fixed by the new user management infrastructure added in Confluence 3.5, including "Internal with LDAP Authentication" directory support. If you have any further issues with LDAP pagination support in a recent version of Confluence, please raise a new support case.

            Richard Atkins added a comment - This is fixed by the new user management infrastructure added in Confluence 3.5, including "Internal with LDAP Authentication" directory support. If you have any further issues with LDAP pagination support in a recent version of Confluence, please raise a new support case.

            Hello,

            is their any progress in this issue?
            We came along the same problem and had to raise the page size of the Active Directory as a workaround. As the AD will continue to grow and raising the page size endlessly is no option to us, we are curious if the aforementioned improvements will make it into a Confluence release in the near future.

            Tino Winkler [Communardo] added a comment - Hello, is their any progress in this issue? We came along the same problem and had to raise the page size of the Active Directory as a workaround. As the AD will continue to grow and raising the page size endlessly is no option to us, we are curious if the aforementioned improvements will make it into a Confluence release in the near future.

            Peter,

            I appreciate the quick response and understand the position you are in. I have to admit, I am a bit frustrated with this. This started off as a bug (CSP-17940). I have many users that are in more than 20 AD groups. As you can imagine, this includes importent content consumers and contributors such as executives, HR staff, etc. as they tend to collect a lot of access. They cannot authenticate to Confluence at all. So, in some ways, the wiki is useless to me as I have random and important users that cannot access the content therein.

            After a long process of trying to determine the cause including a man-week or two of investigation by our IT staff, we narrow it down. We are told to submit the problem as an enhancement request (CONF-12219, this request). Now, I find out you cannot give me any ETA on a solution (cetainly not your fault unless you just happen to be in charge of development). There are enhancement requests out here that are over a year old and they have not been moved on. This does not give me a warm fuzzy feeling.

            It looks like my options are pretty ugly:

            (1) Migrate our content to a platform that supports Active Directory. This would be a very painful task as we have a lot of content (10K+ pages, 40K+ attachments, etc.) and have significantly customized the UI. This is not a win for anyone.

            (2) Install Crowd. While I appreciate the suggestion, it is problematic on several fronts. Even if you gave me the software, we are talking more hardware and significant configuration effort. It is not our current SSO strategy. To be honest, given the rather disasterous authentication experience we have been having with Confluence, I think it would be a pretty tough sell as our strategy. And, I have a tough time swallowing the need for an additional product when I see this a bug in Confluence.

            (3) Reduce the number of AD groups our users are in. This is not workable as, there are business reasons this security is setup in the first place.

            (4) Hope that you guys implement it soon. This is not a winning or proactive approach. I cannot simply tell our executives that "it's coming" but, we have no idea when.

            Now, I understand that you have to service the requests of many customers and prioritize your resources. But, as a paying maintenance customer, I also expect bugs to be addressed in a timely fashion. Look at it from my point of view: Confluence is an Enterprise Wiki. So, it should support a modest sized group of users (1500-2000 in my case). Confluence also supports AD. This is quite reasonable considering it has the largest market share of any directory our there. But, Confluence does not support LDAP request paging? So, any organization of sufficient size or complexity (as reflected in its AD) cannot use LDAP. And, even if they were willing to maintain two directories (I am not), given the rather simplistic user management tools inside Confluence, that mean they can't use Confluence. How can this be anything but a bug?

            I am not asking something of Confluence that we do not ask of every other Enterprise product we use: talk to our directory. We use quite a few software packages (including quite a few not made by Microsoft) and Confluence is the only one that can't interoperate with AD as we have implemented it. We have already made multiple changes to handle shortcomings in Confluence's authentication mechanisms (e.g. nested groups). But, this is one we don't have the power to work around.

            I really don't mean to be difficult here. We have received good support from Atlassian in the past. But, I don't see how this is a reasonable position for you to take in this case. Maybe there are issues I don't understand here. Maybe there is a work-around I am not seeing. I will try to give you a call this morning to discuss.

            Thanks! -RRC

            Robert Cottingham added a comment - Peter, I appreciate the quick response and understand the position you are in. I have to admit, I am a bit frustrated with this. This started off as a bug (CSP-17940). I have many users that are in more than 20 AD groups. As you can imagine, this includes importent content consumers and contributors such as executives, HR staff, etc. as they tend to collect a lot of access. They cannot authenticate to Confluence at all. So, in some ways, the wiki is useless to me as I have random and important users that cannot access the content therein. After a long process of trying to determine the cause including a man-week or two of investigation by our IT staff, we narrow it down. We are told to submit the problem as an enhancement request ( CONF-12219 , this request). Now, I find out you cannot give me any ETA on a solution (cetainly not your fault unless you just happen to be in charge of development). There are enhancement requests out here that are over a year old and they have not been moved on. This does not give me a warm fuzzy feeling. It looks like my options are pretty ugly: (1) Migrate our content to a platform that supports Active Directory. This would be a very painful task as we have a lot of content (10K+ pages, 40K+ attachments, etc.) and have significantly customized the UI. This is not a win for anyone. (2) Install Crowd. While I appreciate the suggestion, it is problematic on several fronts. Even if you gave me the software, we are talking more hardware and significant configuration effort. It is not our current SSO strategy. To be honest, given the rather disasterous authentication experience we have been having with Confluence, I think it would be a pretty tough sell as our strategy. And, I have a tough time swallowing the need for an additional product when I see this a bug in Confluence. (3) Reduce the number of AD groups our users are in. This is not workable as, there are business reasons this security is setup in the first place. (4) Hope that you guys implement it soon. This is not a winning or proactive approach. I cannot simply tell our executives that "it's coming" but, we have no idea when. Now, I understand that you have to service the requests of many customers and prioritize your resources. But, as a paying maintenance customer, I also expect bugs to be addressed in a timely fashion. Look at it from my point of view: Confluence is an Enterprise Wiki. So, it should support a modest sized group of users (1500-2000 in my case). Confluence also supports AD. This is quite reasonable considering it has the largest market share of any directory our there. But, Confluence does not support LDAP request paging? So, any organization of sufficient size or complexity (as reflected in its AD) cannot use LDAP. And, even if they were willing to maintain two directories (I am not), given the rather simplistic user management tools inside Confluence, that mean they can't use Confluence. How can this be anything but a bug? I am not asking something of Confluence that we do not ask of every other Enterprise product we use: talk to our directory. We use quite a few software packages (including quite a few not made by Microsoft) and Confluence is the only one that can't interoperate with AD as we have implemented it. We have already made multiple changes to handle shortcomings in Confluence's authentication mechanisms (e.g. nested groups). But, this is one we don't have the power to work around. I really don't mean to be difficult here. We have received good support from Atlassian in the past. But, I don't see how this is a reasonable position for you to take in this case. Maybe there are issues I don't understand here. Maybe there is a work-around I am not seeing. I will try to give you a call this morning to discuss. Thanks! -RRC

            Hi Robert,

            The only thing I know at this point, in terms of timelines, is "it's coming".

            In other words, more robust LDAP support is being built into future versions of just about every one of Atlassian's products, including, of course, Confluence, but I don't know much/anything about delivery timelines.

            And, you probably won't love me for suggesting this, but Crowd - our single sign-on/identity/user-management product - can fix this issue.

            http://www.atlassian.com/software/crowd/

            Sorry - I know that's not what you wanted to hear at this point, but it's really our only/best option at this point.

            There is definitely some very significant percentage of our customers who use the LDAP option with Confluence, so I know it works in most cases, but it's just not yet as robust as it could be. Hopefully that will be remedied before too long.

            Peter Smith (Atlassian) added a comment - Hi Robert, The only thing I know at this point, in terms of timelines, is "it's coming". In other words, more robust LDAP support is being built into future versions of just about every one of Atlassian's products, including, of course, Confluence, but I don't know much/anything about delivery timelines. And, you probably won't love me for suggesting this, but Crowd - our single sign-on/identity/user-management product - can fix this issue. http://www.atlassian.com/software/crowd/ Sorry - I know that's not what you wanted to hear at this point, but it's really our only/best option at this point. There is definitely some very significant percentage of our customers who use the LDAP option with Confluence, so I know it works in most cases, but it's just not yet as robust as it could be. Hopefully that will be remedied before too long.

            Peter,

            Is there any ETA you could give us for some feedback on this issue? Currently, we have quite a few users unable to access Confluence as they belong to more than 20 AD groups. This means that we cannot use the Wiki for mission critical content as our staff cannot be guaranteed access. If we were doing something strange with Confluence, I would understand a potentially long wait time. But, we are simply authenticating our user community via Active Directory. This seems like a pretty routine use case to me. Any feedback you might be able to provide us would be greatly appreciated.

            Thanks! -RRC

            Robert Cottingham added a comment - Peter, Is there any ETA you could give us for some feedback on this issue? Currently, we have quite a few users unable to access Confluence as they belong to more than 20 AD groups. This means that we cannot use the Wiki for mission critical content as our staff cannot be guaranteed access. If we were doing something strange with Confluence, I would understand a potentially long wait time. But, we are simply authenticating our user community via Active Directory. This seems like a pretty routine use case to me. Any feedback you might be able to provide us would be greatly appreciated. Thanks! -RRC

            I have discussed option 2 with our primary AD expert here and we are unsure as to how, specifically, to turn off the "paged result mode." If you could provide some insight as to the steps that need to be taken to do this, it would be much appreciated. This would also allow us to get a better idea of what the implications might be for our other applications and for performance.

            Was there any word on the possibility of implementing the LDAP paging control referenced above?

            David Duwe added a comment - I have discussed option 2 with our primary AD expert here and we are unsure as to how, specifically, to turn off the "paged result mode." If you could provide some insight as to the steps that need to be taken to do this, it would be much appreciated. This would also allow us to get a better idea of what the implications might be for our other applications and for performance. Was there any word on the possibility of implementing the LDAP paging control referenced above?

            Hi David,

            I guess that option 2) from the support case is not a good option - turning off 'paged result mode' on AD?

            Would that cause problems with other applications, or would it be a big performance hit?

            Peter Smith (Atlassian) added a comment - Hi David, I guess that option 2) from the support case is not a good option - turning off 'paged result mode' on AD? Would that cause problems with other applications, or would it be a big performance hit?

            David Duwe added a comment -

            This LDAP issue has also rendered Confluence unable to translate Active Directory group memberships from AD to Confluence for users who are in greater than 20 AD groups. Users with no group memberships cannot use Confluence whatsoever after logging on. Placing them in a Confluence-originated group as a workaround is not feasible for us. This is an increasing problem with our HR and Accounting departments. This is impacting our ability to use Confluence as our Wiki solution. Please see support.atlassian.com ticket (CSP-17940 and CSP-20630).

            David Duwe added a comment - This LDAP issue has also rendered Confluence unable to translate Active Directory group memberships from AD to Confluence for users who are in greater than 20 AD groups. Users with no group memberships cannot use Confluence whatsoever after logging on. Placing them in a Confluence-originated group as a workaround is not feasible for us. This is an increasing problem with our HR and Accounting departments. This is impacting our ability to use Confluence as our Wiki solution. Please see support.atlassian.com ticket (CSP-17940 and CSP-20630).

              Unassigned Unassigned
              b4a187db0d56 David Duwe
              Votes:
              4 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: