Thanks very much; just the sort of feedback we're looking for.

Based on this, it sounds like a user's group should be determined by the success or failure of an arbitrary LDAP search. That would allow us to define a virtual group for "all users who's manager is Employee #43043".

--Jeff

It would be neat if you could add support for LDAP Groups so that you can create a full JIRA account out of LDAP information. Without haviong to create the user in JIRA.
We have taught our admin staff how to create users in LDAP, so this would save us a lot of work.

Furhermore, a hook for Single-Sign-On would also help a lot.

Cheers,
Ingomar

<provider class="com.opensymphony.module.user.provider.ldap.LDAPCredentialsProvider">
<property name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</property>
<property name="java.naming.provider.url">ldap://ldaphostname:389</property>
<property name="java.naming.security.authentication">simple</property>

<property name="searchBase">o=companyname,c=countrycode</property>
<property name="uidSearchName">uid</property>
<property name="query">(&(objectClass=posixAccount)(uid=%s))"</property>

<property name="exclusive-access">true</property>
<property name="cacheTimeout">10</property>

</provider>

Here the "query" property is a template for real ldap search query,
'%s' is later replaced with the property named uidSearchName. I would suggest using something like this, but more flexible (with arbitrary number of components to insert, maybe something printf-like). And every LDAP attribute name you would choose to store some value for profile or access credential should also be configurable.

I apologize to the user community but I'm ashamed to release our current modules, they are awfull mess. This is not something that should be associated with our company in any way I'v started rewriting them, but didn't have time to get it done... And I also promise to release them if I'll rewrite them before LDAP support is fully present JIRA

Ideally Jira's group admin would allow for arbitrary LDAP queries which would produce group, allow for direct group importing in groups were already present and then let the admins create jira-only groups. For the LDAP-based groups, please create an interface which lists all the available groups from LDAP with giving the admin the option of choosing which groups should be used in JIRA (ie, visible in the other interfaces) and under what name.

these needs are because we want to use JIRA for internal and external users. Internal users are stored into LDAP, but external users must be stored in JIRA databse

+1, definitely

we also need what Richard describes.

at least, we do need to use LDAP with groups, and not only for authenticating: we are already defining roles for our applications.
these roles are currently duplicated in Jira.

A Single-Sign-On integration is not very simple due to the SPNEGO (Simple and Protected GSS-API Negotiation Mechanism). I know only the product JCSI SSO from Wedgetail.

I hope that someone knows how to combine JCSI SSO and OSUser.

Links:
http://www.wedgetail.com/jcsi/sso/index.html
http://www.opensymphony.com/osuser

Basically, it uses groupOfUniqueNames.

So, you specify that a bit of the app is restricted to members of the groupOfUniqueNames identified by a DN.

So, given a base, maybe plug in the project key to find who has what privs:

such as

cn=pico-developers,ou=pico,ou=projects,o=codehaus

Grab that object, and iterate to see what the members are (defined by their DNs).

One minor issue for us is that all our users are in LDAP (external) however JIRA still offers the CHANGE_PASSWORD functionality on the edit profile screen (from what I see), however this does not make sense. I'm not sure of the exact impact of turning ON external user management, however with this on it is still possible to get to this change password functionality, which we can use to change a password, however the password doesn't really get set in our LDAP external repository so it is confusing for the user.

So for us, whilst externalising groups is not an immediate need, addressing the above at least would be good. Hopefully these comments are relevant to this issue.

Thanks.

PS For our home groups apps we use Weblogic Novell authentication provider which has all the appropriate settings for configuing ldap user and group details (e.g. search bases etc).

Managing groups within Jira is fine for us as there are far more granular groups in Jira than we have in our LDAP (Active Directory). Hopefully the level of integration with LDAP will be configurable.

LDAPS is supported on Java 1.4.2 and above. Just specify ldaps://... in your URL

It looks like its going to integrate very well with our existing user base. Is this an idea that Jira will be employing? Create its own inheritable schema for permissions/grouping? Would that be easier than trying to integrate with posix grouping? If you span multiple departments all with the same wheel ideas the overlap might not give the permissions as intended for each group.

2c,
-a

So for the user authentication piece, I agree with Grigoriy V. Kuznetsov that we should be able to define our own search filter resulting in a list of valid entries against which authentication occurs. This way if I want to allow users to access Jira based on group membership, I can do that. Or, if I want to allow users to access Jira based on a custom attribute or object type (perhaps JiraUser, for example), I should be able to do that too.

However, getting LDAP integration to work can be quite a trick. And modifying schemas and understanding the nuances of search filters can be quite daunting. So, it should work out-of-the-box without much customization (ie authenticate against uid=username,dc=example,dc=org).

I also agree with Richard THIBAULT about the ability to have "local" Jira users and groups that don't appear in the LDAP directory. So add +1 for me to his comment.

Finally, changing LDAP passwords: Our configuration choices should be at a finer level, an option like "Can user change password". If jira can pull off changing an LDAP password, great, but I still want the choice of limiting where my users can change their LDAP password. Maybe I want them to change their password through an internal page that lists corporate password policies, etc. In this case, I don't want Jira to even offer the choice (or maybe give a customizable URL pointer to where they can). Or maybe I don't care where they change their password, just as long as they change it.

Anyway, I look forward to seeing the final result. I'm sure it will be great!

We are hoping to put someone on this in the next few months. I can't give you a more accurate timeline than that, as it depends on hiring of new developers.

Cheers,
Scott

Regarding use of LDAP. Sounds great. We also use Oracle's dbms_ldap package to synronize external DB with Oracle's OID. We've written LDAP triggers to externalize managing users. Would like to do same for Jira. Haven't found example of how to do that yet. Could you get with Oracle to formulate an API much like they already have so that our triggers can hit Jira as well? If you like, I could give you the name of an OID expert who you could contact.

Charlie
5/4/05

Kiyomi - May 12, 05

What I would like is a more flexible way to link LDAP accounts to the Jira information.

When a user logs in, I want the user object to be located by sAMAccountName, but I want the Jira information to be linked based on gUID. The Account name of the user may change!!! THe guid will not.

This would basically mean the integration of a new LDAP config setting: unique.attribute, or something.

Please provide new plugin types for

• authentication
• authorization
• role mapping
• auditing (optional)

The default plugins can be a ldap authentication (http://www.atlassian.com/software/jira/docs/latest/ldap.html) plugin and an OSUser authentication/authorization plugin.

With the plugin type interface other developers or Atlassian can implement JCIFS / NTLM authentication plugins, Vintela Single Sign-On for Java (VSJ) plugins etc.

A JIRA administrator should be able to select and configure more than one authentication plugin, e.g. to allow a failover with an external user doesn't exists in the active directory but in the JIRA database.

Cheers,
Nick

Charlie
6/22/05

Cheers,
Nick

The Atlassian User project is working towards better LDAP integration. We're at an early stage where we wish to test the software's ability to map to different LDAP schemata and are looking for test data.

You might find the following link useful for explaining the current state of the project. Leave a comment on the page or let me know (nick@atlassian.com) if you have any further questions.

http://confluence.atlassian.com/pages/viewpage.action?pageId=122526

Cheers,
Nick

<http://www.stanford.edu/~quanah/directory/email/>

Although this is talking about email clients, items 1,2, and 3 all apply here.

Also, I think there is an over-emphasis here about authenticating TO something from Jira. If Jira is going to survive as a product that wants to promote its capabilities of integrating in single sign-on environments, it is going to have to understand that users have authenticated prior to even getting to Jira. For example, we do this at Stanford by front-ending tomcat application with our opensource webauth product <http://webauth.stanford.edu>. This assures the identity of a user (and whether or not they are authorized to use the resource, almost as important) long before they get to the application. In an optimal world, Jira would be able to take in user identity information passed into it from Apache. This is what we do with our locally written Tomcat applications, and we also have vendors who have been willing to implement these capabilities (since in the long term, they apply to many more clients than Stanford). We also have some samples of JNDI with Kerberos to talk to LDAP if that would be interest to you.

Regards,
Quanah

if you want a real SSO in a windows enviroment, you have to use e.g. Vintela Single Sign-on for Java (VSJ) (http://www.vintela.com/products/vsj/index.php). Only one login to your computer in the morning and you are authenticated against any web app which uses VSJ. I still hope that Atlassian will provide a plug in for VSJ.

Cheers,
Lars

Authentication is fairly easy - a SSO system like webauth can add a cookie to requests, and there's a hook in JIRA where you can add code to validate the cookie and automatically log users in:

http://opensource.atlassian.com/seraph/sso.html

However authorization (group management) is more difficult, and not AFAICT dealt with by frameworks like Webauth. In JIRA we need to be able to run queries like "show me all members of a group", and "show me all users in group 'jira-developers' with address matching '*@stanford.edu'". This is what the user management module does that Nick is talking about.

Thanks for the SSO link, it is very useful, and should resolve my SSO bits with Webauth.

However, the points in my previous comment still apply. We have a pool of LDAP servers (running OpenLDAP, in fact) that I run and maintain. However, the Jira LDAP stuff as currently implemented would never be able to talk to them. The basic LDAP model above appears to be based off of LDAP V2, which has been deprecated for a long time. To be a worthwhile LDAP module, it needs to support the varoius LDAP V3 bind mechanisms, and I know for a fact that JNDI does this, because we use JNDI extensively now to talk to our LDAP servers.

As for your question about posixGroup, that is one way to put together group information, but that is really about UNIX group ID numbers. This is really not an LDAP group concept. "groupOfNames" is another (and what I use), and is really what most LDAP group memberships is based upon. "groupOfUniqueNames" is another objectClass dealing with groups, but generally "groupOfNames" is used instead. Again, the key to providing worthwhile LDAP support is to make it so that you can work with the LDAP servers people have deployed as opposed to what a lot of companies have done, which is to try to force the LDAP servers to work the way the company thinks they should (and those companies are often very very wrong...). And of course, someone might have their own schema defined objectClass that is used to create groups. Or, they might have an attribute that is located inside an entry that lists the groups a person belongs to.

So some food for thought there.

--Quanah

I'm sure Nick would be very interested in any feedback you could give on what we're developing:

http://confluence.atlassian.com/pages/viewpage.action?pageId=122526

It sounds fairly flexible, letting users specify the LDAP queries involved, but in practice we'll need feedback to know if it is flexible enough.

As for authentication, OSUser and AUser both use the trick of getting the LDAP directory to authenticate a user with the supplied password (not doing the password comparison themselves). Thus JIRA doesn't care about the auth details (password formats etc). Is this what you were getting at? What do you mean by the "LDAP V2 model"?

Cheers,
Jeff

I'll follow that link.

On the "LDAP v2" part, what I mean is, the entire concept of using "usernames" and "passwords" is the LDAP V2 bind model. LDAP V3 allows other methods (like Certificates, Kerberos, etc). At Stanford, there are no passwords stored in the LDAP server at all. You cannot authenticate a user with a supplied password in any way, because there is nothing for it to compare that password to. If I wanted the JIRA application to be doing data lookups in our LDAP server, I'd assign it a Kerberos Keytab, and then have JIRA use the kerberos credentials from that via JDNI to do SASL/GSSAPI binds to our server to look up group information. There is no password involved anywhere, and the LDAP Server knows what DN to map the JIRA connection to via the Kerberos identity assigned to it.

--Quanah

http://rfc.net/rfc2829.html

--Quanah

CONF-5581

Any chance the JIRA and Confluence teams will get themselves synchronized on the LDAP thing and permit users who use both Atlassian products to perform one glorious handover of users to LDAP? (Fingers crossed...)

Unfortunately we do not have an estimate at the moment.

Thanks,
Anton

Have your SSO plans confused the AtlassianUser/Polis adoption plans?

Crowd

Cheers,
Nick

Is there generally a clear mapping from LDAP groups to JIRA groups?
Can't answer this as we are currently just looking at JIRA but our groups are primarily by department, and then divided by teams in different departments. So project teams would be made up of users from multiple groups in the LDAP...

Is there generally a clear mapping from LDAP groups to JIRA groups?
At our site LDAP stores all access information for everyone which is all restricted via group policies. (similar to how Jeff describes)
So yes for our case there is a very clear mapping.

Using Crowd, you can define your groups in LDAP/Crowd/Custom DB and JIRA will pick up all of the group memberships that are changed. Crowd by default has an option enabled that caches the group memberships for 5 minutes, but this can be adjusted if necessary. Using this new product will allow you to have the flexible security rules you are looking for.

http://www.atlassian.com/Crowd

Is the current answer to use Crowd? Or will there be any development to be able to use groups from LDAP?

In our case, we very much need the ability to tie into LDAP groups (as we store a LARGE amount of group information in LDAP which is programatically maintained....we really try to avoid double work ).

Thanks.

While Crowd has all the bells and whistles.
At the price it's way over the top when you just want user and group administration from and existing LDAP system.
Considering that JIRA is cheaper than Crowd at the moment and all.

I have just finished modifying atlassian-user for BT's use for confluence.. and to be honest, its very good. There is scant documentation though, but with the source code, you can figure out what is going on.

So, for me, if JIRA uses atlassian-user under the covers that would be good, but it doesnt. Anyone got any other frameworks to run between JIRA and LDAP to delagate groups and users to LDAP. atlassian-user is exactly the functionality we require..

This thread started in July 2003.. thats 3 years ago.. come on. come on.

Now Crowd is here, and it feels like we are being asked to pay a huge fee for what ought to be something built into the JIRA product itself. Really bad. If Atlassian wants to call this "legendary support", well it sounds like hollow cynicism to me. "Well, Mr. CIO, this is a great product, but to integrate it properly with your LDAP directory, you have to hire a Java programmer... or pay this small extra fee, heh heh heh."

On this issue, in particular...even Fisheye has support for LDAP groups...why is it so hard to add to an issue tracking system?

Also, for us as wel this will likely make the difference between sticking with our Professional license vs. upgrading to Enterprise – we're looking at rolling Jira beyond the one department using it but need LDAP integration for that (one of the main reasons we're even looking at the Enterprise version actually).

Justen was pointing out that there was a solution out there that would work now. It does cost money, and we don't intend it to be the final solution. Sorry for not pointing that out.

Thanks for your feedback (especially about Crowd pricing) - I want to let you know that the noise you make does get through, and we are doing our best efforts to have shorter, quicker releases, where we can get more features in, and attack more of the popular features (this is now 8th most popular feature).

Cheers,
Scott

Scott, can you give any timeframe when this will be implemented?
LDAP support is very important for us. To have Jira included in our product selection, we would at least have to know what to expect ...

Thanks,
Michael

Regards
Damon,
Application Development Team
Amnesty International

I would say that most people who use LDAP use it for storing authorization data. After all, LDAP is not an authentication system, but as a directory server it is ideal for storing authorization information – it's why Microsoft Active directory uses LDAP for its authorization data, but Kerberos as its authentication system. Using LDAP for authentication and not authorization is just fundamentally misguided.

At British Telecom, we have a few LDAP servers, one for authentication (active directory), and one for profiles (Novell), and others. Although this may seem silly to some (I think so too), it actually works very well for BT. This is a typical setup though in my expererience, as LDAP as the first proper server mechanism to enable Single Sign on. So like it or not, in established corporations, LDAP is going to be around for a long while, and has good penetration, both for authentication, authorisation and profile data.

atlassian-user is a good mechanism of abstracting this LDAP and other mechanisms though. The interfaces for atlassian user are well thought out. I'm sure that they will morph over time. But its a damned good start.

We also store other information regarding groupings of people in Peoplesoft (oracle db).

What I have done at BT is write a load of java which does all the effort with out LDAPs and oracle and then write an atlassian-user and os-user implementation to use it. This allows us to use the same code base for jira and confluence without hacks and dirtiness. But its a lot of effort to get round the fact that both these produts use different user management.

I know Atlassian are working out the tasks needed to convert jira to atlassian-user. I also know that the work is an extensive change for the product so may come in numerous releases.

All I hope is that it gets started and completed. I look forward to the day when this issue changes state to "In Progress"

It's good to avoid password management outside of JIRA, but it would be much better to manage also the users and groups in LDAP.

Using Crowd is not possible in our environment: for internal directories, it only allows internal user, but no LDAP user.

Has someone implemented http://confluence.atlassian.com/display/DOC/Automatically+Adding+LDAP+users+to+the+confluence-users+Group. for JIRA?

Thanks,
Uwe

you used "finger tap" in a comment for this issue. Sorry, but as a
German I could not understand what you mean...

Thanks,
Uwe

Thanks!

The result is I wrote an RCP app that talks to AD via LDAP, that has a JIRA plugin that allows a given LDAP user to be automatically be provisioned through the JIRA SOAP interface. I also added a neat right click 'add entire company' as I was fed up with automated Jira emails bouncing due to the user not existing and the fact I had to turn off user auto-creation (causing the bounce) as people got created with their email address (my company likes just the ID thanks - no option to only add by ID, shame!).

This probably won't work very will for the 10K+ Jira user bases mentioned (I think it took an hour to chew through 1000) , as the JIRA SOAP api doesn't (AFAIK) yet provide a method to nominate a given group, eg 'jira-users', you have to retrieve the RemoteGroup which also contains serialised members - with 10K users, thats going to slow you down a tad. Anyone think this would be useful for them, it only helps with automated user registrations...

A tickbox to 'autoprovision' from LDAP on login sure would be a nice start towards addressing this! I haven't yet had the headache of LDAP group requests but that's coming. Perhaps a plugin like confluence CSUM would help...

4years now

It seems like there are quite a few votes for it and it's been open for quite some time.

Should I start developing a solution in house? Or will JIRA be able to do the same integration that Confluence has had for some time, now?

http://www.faqs.org/rfcs/rfc2307.html

Accordingly, it is meant as an abstraction of a group of user accounts.

;o)

Well, that's what I'm hoping to hear once the good folk from Atlassian and the JIRA team come back from well deserved holidays.

This feature is (at the time of writing) #8 most popular:
http://jira.atlassian.com/browse/JRA?report=com.atlassian.jira.plugin.system.project:popularissues-panel

and taking a look at the others in the top 10, they all date from late 2002 to mid 2004, bar 1 from 2005. All with more votes.

Again, looking at that list, only 2 of the top x0 are down for v4.0. Would be very interesting to see a report showing time to closure of top voted, watched, and commented issues, which may or may not show any correlation. At least we, as users, would then know whether voting and commenting had any impact on development priorities. I assume it does, but that this must be balanced with security and stability issues, along with resource constraints etc.

I do greatly appreciate the incremental improvements that have been made in the last year. Pain points for out team around time tracking have been addressed, and the improvements to the version and component panels is fantastic. The integration with Confluence is coming along nicely. All things I have voted on that are major developments completed in the last year.

Hopefully my next hot button (this issue) is bubbling to the top too!

cheers, Nick

• we're a university trying to turn-key scale JIRA + Confluence out to all our research groups, commercial groups, and internal IT projects.
• This is a very diverse group, so setup and configuration becomes a massive burden, particularly when trying to provide a quick response.
• We're developing plugins to streamline management of projects and project schemes, and some visualisations of wiki content to aid navigation and interaction.
• Crowd is not an option for us as we've currently migrating from our CoSign based SSO solution to Shibboleth/SAML based Federated IAM. Ideally Shibboleth will provide identity and LDAP provide groups in the short term.

We are interested in hearing from anyone who has developed their own group import solution for JIRA, as we may have to get there ourselves before Atlassian User arrives. Any links or example code greatly appreciated!

cheers, Nick

• we're a university trying to turn-key scale JIRA + Confluence out to
  all our research groups, commercial groups, and internal IT projects.
• This is a very diverse group, so setup and configuration becomes a
  massive burden, particularly when trying to provide a quick response.
• We're developing plugins to streamline management of projects and
  project schemes, and some visualisations of wiki content to aid
  navigation and interaction.
• Crowd is not an option for us as we've currently migrating from our
  CoSign based SSO solution to Shibboleth/SAML based Federated IAM.
  Ideally Shibboleth will provide identity and LDAP provide groups in the
  short term.

This sounds almost identical to us! I've held off trying to do the more
fully LDAP integration with Confluence because I was wanting to deal
with both Confluence and JIRA at the same time, but I'm beginning to
lose hope that it will be ready for JIRA any time in the foreseeable
future. We too are a university with a lot of diverse groups, and trying
to manage the user accounts in both Confluence and JIRA is turning out
to be a bit of a nightmare. We too have no interest in using Crowd
because we're standardizing on CAS/Shibboleth/SAML for our SSO
infrastructure. We don't see buying yet another add-on product to make
all of our account management even more complicated as a solution to
this problem.

I developed simple java application that basically loads data from LDAP and from Jira application (thro SOAP) and makes diff to add new users to Jira. This application is based on Atlassian Jira SOAP client example.

You can download source code here. I've attached it into this Jira issue.
http://jira.atlassian.com/secure/attachment/24151/ldap-syncer.tar.gz

You can find basic instruction of how to configure, build and run this application into README.txt file. For detailed instruction please see source code and Atlassian Jira SOAP client example.

Hope it helps,
Alex

http://jira.atlassian.com/browse/JRA-1962?focusedCommentId=93299#action_93299

It works pretty good for our environment with more than 50K users ( total, not active ).

You are talking about 50k users, I am getting following error for 10k users

This is same error as Atlassian ldap importer can you please throw a bit of light on it.

12:40:11,996 INFO org.springframework.beans.factory.support.DefaultListableBean
Factory:275 - Pre-instantiating singletons in org.springframework.beans.factory.
support.DefaultListableBeanFactory@228a02: defining beans [jiraSoapClient,contex
tSource,ldapTemplate,ldapClient,jiraLdapSyncer]; root of factory hierarchy
Exception in thread "main" org.springframework.ldap.LimitExceededException: [LDA
P: error code 4 - Sizelimit Exceeded]; nested exception is javax.naming.SizeLimi
tExceededException: [LDAP: error code 4 - Sizelimit Exceeded]; remaining name ''

I'm not sure, but it looks like your LDAP directory doesn't support huge amount results.

In my application I use Spring Framework to make LDAP programming easy and fun. Atlassian team uses it also.

I found that they encountered the same bug as you have
http://jira.atlassian.com/browse/CWD-134
and they resolved it using technology for paging LDAP results that provides Spring framework
http://static.springframework.org/spring-ldap/docs/1.1.1/reference/#d0e993

So I would recommend to change source code of my application to retrieve LDAP results partially as described on the spring ldap docs.

Lets move our discussion offline because here are too many watchers ( sorry guys )

Alex

From a user management standpoint it would be nice to have the login part based upon LDAP/AD groups. The rest for my sake could be confined to Jira since now there is a role based option.

I am using timgolden's active directory python module http://tgolden.sc.sabren.com/python/active_directory.html to get all users and than pushing them to JIRA Using SOAP call and that is working pretty well for me.
You can get groups as well as all users and it does not give any exception for atleast 3k users which I have imported can't comment for more.

1. First using JIRA user management
   • Wrote a fairly simple script that extracted information from LDAP/Active directory and loaded it into a table
   • Ran an SQL query on the table that produced a jelly script that automatically added all the user information into JIRA (delegating authentication to LDAP).
   • This was a temporary measure until we moved to Crowd - it works fine, but does manual updates for changes
2. Move JIRA (and Confluence) to Crowd
   • Initially Crowd was lacking support for our migration, so we did 1) above first.
   • With Crowd 1.3 there is now enough to support our migration

Crowd is nice, but having to pay for an additional product because of lack of core functionality in Jira is not acceptable. Give Crowd out for free, or build in the functionality as promised and expected.

We've been using Confluence's LDAP integration for years now with great success – equivalent functionality in Jira is all that we're asking for (I realize that may not be simple but I'd presume a good bit of the Confluence code could be used in Jira).

We have an Enterprise license and this has significantly slowed down rollout within our organization as well as given the product something of a bad name internally.

Let alone bring it into our shiboleth based federated identity management framework. As you've suggested this too is a major impediment to adoption of Jira.. we simply can't manage people and groups responsively enough to keep user groups happy... well, not without having a dedicated jira system admin, which is just not viable as a support model.

Bringing Jira onto atlassian user is clearly requires a difficult refactoring, but this is a major and constant burden on many customers. It's a core subsystem that drives the rest of the system, and in that respect is a fundamental dependency. It's been top 10 on the popular issues list for quite some time.

Come on Atlassian, share in our pain.. :o)

Why don't atlassian write an OSUser -> atlassian user adaptor..

This is just an implementation of osser (3 interfaces) and an adaptor (3-6 classes) to atlassian-user.

This way, at least people, who have atlassian-user implementations, or want to do a better job of ldap integration, can use this.. without actually refactoring everything internally to jira..

This piece of wrk would take a week of atlassian's time.. its really not that hard.

Obviously its not a proper job, but the pain of all the above people, would be reduced a lot.

Here's our problem: one team enter tickets on behalf of other people, who may well not have jira accounts. They want to use the reporter field so the user gets emails from jira and so on. The problem is they can't create user accounts. Ideally this would work in the same way as confluence, where the user lookup is against AD.

Here is my workaround. Create a custom field called Reporter visible only on issue create. A post function verifies that the reporter entered is a jira user, or creates them if not. Then it copies this value to the "real" reporter field.

The problem though is that sometimes they forget to put the reporter on create, and when they edit it, they can't find the user (as it only searches jira accounts). It's also confusing because the two fields (real reporter and custom field reporter) look and behave similarly but show different search results (I'm using this).

cheers, jamie

I can partially use Jira's roles to workaround some of this limitation, but not the searching. Altogether the functionality is disappointing - the ability to use the LDAP password in Jira is almost causing more problems than it solves. - Greta

If you are already using Crowd delegated directory (i.e. if Bob's suggestion does not help), can you please create a support case in the Crowd Support project in https://support.atlassian.com, and a Crowd support engineer will help you.

Kind regards,
Ian

I guess a lot of people are still waiting for this implementation to come. I this is a bug the people are reporting, because you promised to implement it in the Jira documentation to persuade people to buy the product.

See:
http://www.atlassian.com/software/jira/docs/v3.12.3/ldap.html
Planned Improvements
In future, we plan to more tightly integrate LDAP into JIRA, so that LDAP groups can be mapped to JIRA groups, and user management can be fully externalised (see Plans for JIRA's LDAP integration). We'd like feedback as we go further with this; please see this issue report for current status, and add your use-case as a comment. Thanks!

There are a lot of use use-cases and only one solution -> CROWD. Please integrate the LDAP authentication feature as promised or offer CROWD as workaround for licensed Jira companies.

This documentation is the basis for our decision to buy Jira and we also bought the support. I don´t think that the support should be to offer additional products!

I would be happy to be informed about your further plans concerning this issue.

Cheers,

Jörg

I guess a lot of people are still waiting for this implementation to come. I this is a bug the people are reporting, because you promised to implement it in the Jira documentation to persuade people to buy the product.

See:
http://www.atlassian.com/software/jira/docs/v3.12.3/ldap.html
Planned Improvements
In future, we plan to more tightly integrate LDAP into JIRA, so that LDAP groups can be mapped to JIRA groups, and user management can be fully externalised (see Plans for JIRA's LDAP integration). We'd like feedback as we go further with this; please see this issue report for current status, and add your use-case as a comment. Thanks!

There are a lot of use use-cases and only one solution -> CROWD. Please integrate the LDAP authentication feature as promised or offer CROWD as workaround for licensed Jira companies.

This documentation is the basis for our decision to buy Jira and we also bought the support. I don´t think that the support should be to offer additional products!

I would be happy to be informed about your further plans concerning this issue.

Cheers,

Jörg"

Couldn't agree more. This ticket has been open for 5 years?! Doesn't seem cool to still be saying "buy Crowd". That approach doesn't even work for MSFT anymore . I need to integrate JIRA into a larger enterprise system. Multiple pieces leverage the same set of users/groups. Isn't that why God invented LDAP and made it an Internet-standard protocol? I support the idea of including Crowd with Enterprise JIRA licenses until you resolve this limitation.

1) Assume Active Directory is read-only.
2) Assume Active Directory is read-write.

All products that claim "LDAP integration" should support at least the first use-case, supporting the second is a nice-to-have...

It's unfortunate that both osuser (Jira and Confluence) and atlassian-user (Confluence only) formats aren't capable of expressing fail-over ldap servers. If your DC goes off-line, despite having another 12 replicated instances you loose access. The same is true for CROWD....

nick@nickdjones.com
021 609 535

On 27/11/2008, at 11:01 PM, "Andy Brook (JIRA)" <jira@atlassian.com>

Yes we are also a victim of this issue and were forced to use crowd for Jira and Bamboo (Confluence works great with ldap).
Yes the licence indeed restrict the usage of 1 server, regrettably you cannot cluster them.

If you really want to, you can buy two licences and since the connection from jira/confluence to crowd is only http you can put a load balancer in between.

We now have an application that runs ever hour, scans all the groups, creates them in Jira, adds/removes people from the groups and creates new users if they don't exist. Also, the groups flatten all nested groups which makes it very usable for us.

That certainly helps auto create users, and when users are removed from Active Directory, Jira does not choke on the missing user... cause they exist, but are not part of any groups.

It was unfortunate that we had to write such a tool. It should be a built in service in Jira.

Can you share those application with the JIRA community? I guess it will be better to do something open-source thus we do not have a way to 'force' Atlassian to keep promises. I guess application can be written even in C# - it gives you smooth integration with Windows environment.
Regards

Btw - the utility was written in C# and the code is extremely simply.

1. Connect to LDAP and Jira
2. Run a filter of both groups and people
3. Track each member in memory as you process the root group
4. Process each group recursively looking for more members to add to the root group
5. Merge the member list in Jira against the member list in memory (may require creating users, subscribing, unsubscribing members)

Status: Short Term Roadmap (was: Open)

What does that mean?

Status: Short Term Roadmap (was: Open)

What does that mean?

It means we are going to take a look at this issue in the short term but its not yet scheduled for a particular release.

• http://confluence.atlassian.com/display/DEV/Feature+Request+Workflow

Kind Regards,

Andrew

+1

+1

...which, just maybe, might make up for all of the companies that don't buy JIRA period because of the lack of LDAP integration. We decided against JIRA for this very reason. We continue to monitor JIRA (obviously), and if this LDAP issue ever gets resolved we'll evaluated it again.

Seems unfortunate to leave potential customers sitting that are ready to hand over their money for such a small and basic feature...

which, just maybe, might make up for all of the companies that don't buy JIRA period because of the lack of LDAP integration

You absolutely right! After several years our company already paid for ent version, but we continue to monitor about LDAP integration... with no luck. Our paid period will over, but LDAP integration will stay at null, I think we don't buy JIRA anymore without this feature enabled.
...

I'm the Integration Product Manager at Atlassian. My responsibilities include Crowd and the effort to unify our user management stack.

If you're not aware, Confluence and Bamboo use atlassian-user, FishEye and Crucible have their own stack, and JIRA uses OSUser. Crowd's LDAP stack is different again. This isn't a pretty situation, and it's one that we honestly don't relish either. I really hate the fact that some of you feel pushed to buy Crowd because JIRA's LDAP support sucks. We'd be much happier if you were buying Crowd because you need the ability to simplify your user management infrastructure, or because you want to integrate your custom apps with your Atlassian stack.

The upshot is that we are going to put Crowd's LDAP stack into both JIRA and Confluence, and then into the rest of the products. This is a large amount of engineering, and in JIRA in particular, will affect a lot of the code. Much of the Crowd team will be helping out on this effort. The work will not be delivered in JIRA 4.0, but it will start as soon as 4.0 ships.

Apologies for the wait, but we are working on this and we will deliver it. Before the bug is old enough to go to high school

Cheers,
Dave.

Please clarify, with this change, are you going to implement LDAP server failover, which is lacking accross the board in all products to date?

Last time I looked Crowd still didn't support failover through federated ldap mirrors. This has pretty much been a reason for not using Crowd to date.

Moving the Crowd LDAP stack to other products is great in terms of a common configuraiton, and I'm sure LDAP integration will be improved, or at least enable future improvement accross all produts. But, it would be a shame to go to all that effort and still not have such long-awaited features (ehm, possibly even fixing recursive group membership )

Is there any roadmap planning decribing the eventual features that this stack would provide?

Cheers,
Andy

There isn't a public roadmap yet, primarily because we don't want to commit to features we may not deliver. We've gotten ourselves into enough trouble as it is

That said, we are looking at LDAP server failover for inclusion in Crowd, and when it makes it into Crowd it'll flow into JIRA. Crowd does recursive group memberships (or nested groups, or sub-groups, depending on your terminology). If you watch CWD-422 you'll be notified when we implement failover.

Cheers,
Dave.

Atlassian-user works fine for confluence and bamboo. Instead of implementing what we have asked for, we are again being told you can't promise anything because you are working on an all new library that 90% of users don't care about. You are spending too much time on new products and new features instead of servicing the ones you have.

Implementing atlassian-user into JIRA would be significantly more work than putting in Crowd's LDAP stack. Crowd has a lot of caching work already in place that we'll need for JIRA & delivering an alternate stack wouldn't happen any faster.

I can appreciate your frustration - in your place I'd probably be significantly less politic - but we are working on this and we will deliver it.

Cheers,
Dave.

Gadgets affect the whole appearance of the system. This means all portlets have to be reimplemented.
Otherwise you get dashboards full of error messages. What I saw as 4.0 beta tester made me cry.
As an admin of a heavily customized Jira installation with many plugins, I doubt I will ever be able to upgrade to 4.0.

My company is paying me for improving our own products with help of Jira (and other tools).
The focus is not on the tool, but on our own quality. So I don't think I'll be allowed to reprogram all our plugins.
Rather we'll stay with 13.3.x and stop renewing our software maintenance license.

This means, even if LDAP will be integrated in 4.x, I will never get it!
And this because of the gadgets.

I'm quite sad about this.

Bettina Zucker