+1 for this idea

I am trying keycloak now and I also want this feature (Keycloak as LDAP server), the reasons are same:

• There are many other products using LDAP only.
• We dont want to do group management in LDAP.

Keycloak failed so I searched its competition and found this issue, but it is disappointing again.

I think, it can be perfect. Because, we have so many Products without crowd authentication.

This would be quite useful.

2017 and still no one at Atlassian has recognized this as low hanging fruit.  So obvious this would significantly enhance the value of Crowd.   It would be great to hear the rational behind not doing this. 

I support the previous statement - we have rather a similar setup, and would have liked to collect our services with Crowd instead of abandoning it, moving everything to alternative directories instead.

This is so disappointing.

Just today we were thinking about buying a 500 user license of Crowd. We have Stash, JIRA, Bamboo, and FishEye/Crucible. They're all authenticated through Active Directory, but it's a real pain for us since the AD instance is corporate, making group management a pain. Crowd seemed like a nice solution to proxy our AD server and give us more flexibility over group membership.

The problem is, we have other tools that authenticate with AD as well (the open source version of Sonatype Nexus being one of them). If Crowd would expose an LDAP interface, it would be ideal for us. Since it doesn't, it's fairly useless. Now we would have to worry about two different authentication mechanisms instead of just one.

I do see that there's a plug-in available, but it's created and supported by a person. It may be fantastic, but we can't really base corporate infrastructure on a plugin created and maintained by a guy who may or may not support it in the future.

I guess that's $2,200 that Atlassian will have to forgo.

I can't imagine we are the only ones in this position. I wonder how much lost business it will take for Atlassian to at least decide to create a 1st party plugin?

This is extremely unfortunate that Atlassian has chosen this path. There is an option however: https://marketplace.atlassian.com/plugins/net.wimpi.crowd.ldap.crowd-ldap-server

I don't understand why you are not looking to implement this feature which would make Crowd infinitely more valuable.
This would seem to be a logical extension of what you state Crowd is designed to do.

Hi Jason,

We've improved the LDAP connectivity functionality in both JIRA and Confluence so that you do not need Crowd to connect up small instances of JIRA/Confluence/Bamboo/Fisheye to an LDAP server.

Crowd is designed to:

• allow complicated configurations of LDAP, where you want to hook up multiple applications with different views of an aggregated userbase
• be external from other applications so that you can manage load and upgrade apps independently of your user management server
• single sign-on between applications configured to use Crowd for authentication
• aliasing users so that they have different usernames for different applications
• support Apache/SVN authentication

Our goals for the medium term are to improve the synchronisation between Crowd and other Atlassian applications. We do not plan to write an interface to Crowd that exposes it as an LDAP server in the medium term.

If this is critical to your deployment, you can:

• write a Crowd plugin, or engage one of our partners to do so, that exposes the userbase in an LDAP format (this has been done in the past); OR
• use Crowd to manage your userbase in an LDAP server. Have Atlassian applications interface with Crowd and your LDAP-only applications interface directly with LDAP. This way, you can use Crowd to manage your LDAP users, groups and memberships but have those applications talk directly to your LDAP server; OR
• write a connector for each of your applications so that they can obtain userbase information from Crowd using Crowd's REST APIs.

Cheers,

-Shihab