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
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.