We configured and have been using Jira's user directories. We are now evaluating Crowd. When we use Crowd, do we disable all user directories in Jira? I have an ldap user directory in crowd. Jira, however, is really mix-mash right now with some percentage of users using Jira's internal user directory, and then next in line it users ldap user directory. We also set up for global permissions a group called jira-login, or maybe that was there already from an older version of Jira. The jira-login group is what the user directories in JIRA were auto-assigning people to if they logged into JIra. It is also the JIRA user directory that the ldap user directory auto-assigns well as it pulls in and synchronizes users. I realized later this was not so great as each user in AD/ldap takes a license. This was not a big deal with having the 10000+ license model, but ideally I would like to fix this if we are moving to using Crowd. Useful/practical thoughts and ideas on these things would be appreciated.
When using JIRA with Crowd, you'd typically keep all your users in Crowd. That way, you can connect Confluence or other Atlassian products and have the same userbase available, and it's also the required configuration for SSO across JIRA, Crowd and any other applications (more info on SSO).
I didn't catch why you're considering using Crowd; if you're happy with JIRA's user directory support, don't plan on integrating any other Atlassian products, and aren't having a performance problem with JIRA then you may not get much value out of Crowd. Even if you are planning on integrating other Atlassian products, JIRA can act as a (limited) Crowd server, which will be sufficient if you only want to provide the same userbase to all Atlassian products.
Regarding sucking down all the LDAP users into JIRA: you're right, this is a less than ideal setup. In Crowd, you can restrict the scope for Users and Groups, which essentially means you can use LDAP filters to limit which users and groups will be synchronised to Crowd. JIRA's LDAP directory configuration should have a similar option, albeit likely cloaked in a slightly different UI.
We have Bamboo and are looking at Stash, and we are making our environment pretty much SSO enabled. It seemed like a good solution to cover all those things.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Okay, that's a good reason to adopt Crowd.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Personally, I keep the internal directory around with an admin-type account in case of emergency or any changes I want to do to Crowd itself, since you cannot modify the LDAP/Crowd directory you're logged in through in most cases.
So, I have the:
Most of the other environments I work in do something similar, with keeping the internal directory to only Admin-type minimum. This way you can manage all of your regular users in one place, then your higher-powered users or accounts from the system itself when necessary.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yep, also a good setup, as long as you have the internal directory below the Crowd directory.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Indeed, that's an important thing to call out.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.