nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Crowd as an LDAP Server

Krzysztof Kiser

Hi,
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?

Accepted answers

Nic Brough -Adaptavist-

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

All comments

Nic Brough -Adaptavist-

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

Charly_81juvl

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.

Nic Brough -Adaptavist-

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"?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

crowd

ldap