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

Crowd as an LDAP Server

I've been wondering, is there any relatively easy way to use Crowd as an LDAP server?

I am currently considering using Crowd, but in addition to Atlassian Apps, I'd like to be able to use it to authenticate other services that support LDAP (e.g. Synology DS).

Is there any way to implement such solution?

2 answers

1 accepted

1 vote
Answer accepted

Crowd is not an LDAP server, it does not have any functionality that would make it look like one.

Is there any work-around based on that question?

For example crowd to be in constant sync with an LDAP server. Im not a dev but most likely they will use the same data ( user details) or whatsoever.

Im in the same boat as the original poster. To me it makes sense to have a single user directory in your infra. Having multiple can complicate the user's experience and also maintenance process. So it will be Crowd or if it does not fulfill the requirements it will be something else.

Im impressed with the UI of Crowd and how easily it can be managed but the luck of intergating it to other services makes me look for alternatives.

Just my 2 cents as a customer.

I'm not sure what you are trying to work-around here, but maybe a bit more about Crowd might help frame that for me.

Crowd provides a user directory for other applications.  Off-the-shelf, that really means mostly Atlassian stuff, but it is possible to use it for others.

You can use Crowd on its own for this, but a lot of us actually use it in front of other directories.  One of its main functions is to take its data from other directories to make it easier to manage for the Atlassian applications, and another function is that it can act as a management system for other directories.

The last time I worked on a serious Crowd installation, the client had something like:

  • LDAP 1 (active directory)
  • Internal directory
  • LDAP 2 (openldap)

There were legal reasons for having 2 separate directories, and the internal directory was needed mostly for temporary (contractor/consultant) accounts for non-employees as they couldn't be added to the LDAPs.  It was actually a lot more complex than that.

Crowd made user management far easier - the Atlassian applications had a single source of users (you didn't have to add eleventy twelve directories to each of them and non-employee accounts to all three separately), and the Crowd UI enabled the user-admins to maintain all the directories in one place.

So, the question is for me, what are you trying to "work around"?

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira Service Management

Jira Service Management Documentation Opportunities

Hello everyone, Hope everyone is safe! A few months ago we posted an article sharing all the new articles and documentation that we, the AMER Jira Service Management team created. As mentioned ...

340 views 0 10
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you