Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Delegated Authority vs ldap connection

Is there a standard rule of thumb for the number of users that one should have in ldap to determine if you use delegated authority vs a standard ldap connection?

The reason I ask is that in the new confluence and jira they are recommending a delegated authority be setup, but crowd support has mentioned that delegated is best for 10000+ users. We have 6000+ allowed to use confluence from a ldap server with 150000+ users so we initially setup crowd with delegated authority and used a script to keep the directory in-sync with changes in the ldap. But with the upgrades to 2.2.X the scripts fail and changes have become problematic. So we need to decide do we drop Delegated and go to the ldap connection or do we stay on delegated and keep hacking at this script.


2 answers

I don't claim to be an expert on Crowd, but for a userbase of 150000+ users (even if only 6000+ are being used in the app), I believe delegated LDAP is the way to go - otherwise you could end up with all 150000+ users making the Crowd directory unnecessarily large.

It doesn't sound good that you need to hack scripts, though. What changes do you need to sync in the directory when working in delegated LDAP? I ask because if it's just user creation, the users should be automatically created in Crowd when they first log in.

Relevant part:

Consider how you would like to add your users to Crowd's Delegated Authentication directory. There are a few options:


* Let Crowd do it for you, at login time. If a user logs in successfully via LDAP authentication but does not yet exist in Crowd, Crowd will automatically add them to the Delegated Authentication directory. You will then need to add the user to any necessary groups, to allow them to access applications where group membership is required.

The script we have is really centered around group-membership. We use group membership to control access to both Jira projects and Confluence spaces. But there are so many groups 150+ for both confluence and jira that the auto add feature wouldnt work. We can grant everyone a simple confluence-users or jira-users membership but the groups are also the format of GP-CFW-BLAH GP-JIRA-FOO GP-JIRA_BLAH even the unforgiveable GP_ CFW-FOO (note the space and the bloody underscore)

In 2.0X the script would check the LDAP and the CROWD see if there were new groups in LDAP with the format and create them in Crowd and then populate them. Then it would add the users to to CROWD if they were in the groups in LDAP but not in Crowd and then it would add the users to the group. It would also do deletes. But the changes in 2.2.X changed such that the operation had to be run per application instead of directory wide on Crowd.

I just tried a new LDAP Connection but what I see is the Synchronization takes 12 hours. And the groups are not created and users are not populated in the groups so no login occurs. I also tried allowing All users to connect to an application from the directory but that too fails.

When I add the groups to the application in the LDAP Directory on crowd set all to false, the users can login but thats unwieldy because groups are created and changed all the time.

Ouch; I see. Sorry I can't help, hopefully someone else can.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events