I’m really unhappy with this issue

We are rolling out the same confirmation onto a network for 250 users. We are able rolling out jira service desk to support this installation. For this we started with 25 jira service deck agents. The plan was then to all AD user as jira customer. This then let all AD user raise service desk issues. As we already use and are happy with crowd we went with crowd. We got crowd to 500 user to covert the 250 full users.  

All our jira customer are full AD users. One of the reasons to go with jira and jira service is within jira you don’t pay for jira customer. For a number of reasons we can’t use local jira users. And we don’t want users to sign up. All users are already in AD.

I’m unhappy with “Workaround” for this problem. Crowd should support jira customers without taking a crowd license. I see this as a bug and not a new feature

tps://jira.atlassian.com/browse/JSDSERVER-1052 – invalid/resolved#

https://jira.atlassian.com/browse/CWD-4116 - won’t fix/ resolved

what I’m really unhappy with is the workaround to pay for more crowd licenses. Pay for the next licence step in crowd + $7000 one off and support each year +£3500. Just to support are AD jira customer

that’s also +$3500 each year to support a bug. That’s move than we paid for crowd to start with. Just to support jira serve desk customer. We have already have paid for crowd for cover are full users.

The other workaround is not to use crowd for jira but I have already paid for crowd. I will still need to pay for crowd to support or other Atlassian application.

In over 20+ years of working with applications I have never had to pay to work around a bug/problem. And then pay over the licenses cost each year for a bug that is not fixed and no time scale to be fixed. This was sold as don’t pay for jira service desk customers. But for use we need to pay $7000 more one off and then +$3500 each year to support jira service desk customers. That makes no sense!

For anyone else who has only recently run in to this, ridiculous, issue; I have just made use of the MIDANAuthenticator courtesy of Alexander Sebastian Jost's comments back in 2016.

I can confirm the MIDANAuthenticator still works and I am using it with Jira version 7.7.0 and Crowd version 3.1.2

Instructions:

1. Set the JIRA internal directory to be above the Crowd directory on JIRA's user directories page.
2. Download the the midan-authenticator-1.1.jar from the github releases page.
3. Copy the .jar in to the [JIRA ROOT]/atlassian-jira/WEB-INF/lib folder
4. Comment out the CrowdSSO authenticator in the [JIRA ROOT]/atlassian-jira/WEB-INF/seraph-config.xml
5. Add a new authenticator:
   <authenticator class="eu.midan.MIDANAuthenticator"/>

How Atlassian still haven't fixed this is incredible. I guess people paying for crazy crowd licenses to accommodate all of their customers is a disincentive.

I guess it's time to implement Jasig CAS. About to abandon Atlassian Crowd ... I haven't tried it, but perhaps the Jasig CAS plug-ins will also allow for Internal Directory authentication? It's a long exercise just to find out...but might be worth doing....

One of the issues with Jasig CAS is I don't think there are plug-ins for Stash and Bamboo. The blogs just talk about Jira + Confluence + Jasig CAS

https://wiki.jasig.org/display/CASC/Configuring+Confluence+with+JASIG+CAS+Client+for+Java+3.1

https://wiki.jasig.org/display/CASC/Configuring+Jira+with+JASIG+CAS+Client+for+Java+3.1

Ryan Hoke,

Please be aware that Atlassian service desk staff think "Crowd" is the "Embedded Crowd" in Jira when you speak to them unless you repeat 12 times..."No...not the embedded crowd...Atlassian Crowd Server".

The embedded Crowd and Jira only count "jira-users" group toward licenses. Therefore, the service desk is correct in stating that "it should not count to licenses".

However, Atlassian Crowd ... different story...and the support staff just doesn't get it.

Edward, please don't get me wrong...I LOVE Atlassian.

However, your suggestion just is another indicator of how out of touch Atlassian seems to be with Product Licensing.

Not everyone has "Unlimited" licenses and can afford $200K/year on this system.

When you are testing in the Lab, and making recommendations, they must fit within the Product Licenses that you offer. And your suggestion does not.

IMPOSSIBLE.

This suggestions is a NON-STARTER. I CANNOT and WILL NOT make my crowd server the "top most" and "default" directory.

I CANNOT create customers in the Crowd directory. It will BLOW AWAY my Crowd Max User license in 2 seconds.

This is a SEVERE blocker issue.

Right, Kerem. As you've already stated, there is a change request concerning customers in the JIRA Internal Directory not being able to log in when Crowd SSO is enabled. There is also a change request for the other side: getting Crowd to recognize customer accounts so it doesn't count them towards the license: https://jira.atlassian.com/browse/JSD-1052.

It seems we are diverting from the main point of this issue. Although making crowd directory writable seems to be solving the case, it is not. In this case, for a customer account which is free in JIRA, you must pay in Crowd. Either, JIRA must allow authentication of local directory users when Crowd SSO enabled (I believe there is already a change request regarding this topic), or Crowd must recognize the customer accounts and does not count them towards license count to be inline with JSD 2.0 licensing strategy.

This ensures that customers created through JIRA Service Desk are created properly in crowd and can authenticate even though they are in no groups.

In Crowd, usually all users created are preferred to be automatically added to the jira-users group. This should not be the case with Service Desk customers. How is this handled?

Here it is: https://jira.atlassian.com/browse/JSD-1052