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; } } }

Jira, Crowd and groups sync

unknown

I am currently testing the configuration for Jira + crowd with identifies backed onto an external LDAP.

Everything seems to work smoothly until we get to the stage in which login's become a requirement. I am unable to perform the login due to the groups not syncing as needed. The groups seem to sync only the initial group linked to gidNumber attribute. The groups defined within the memberOf attribute for a user or the member attribute for groups are not being synced.

The groups them self are loaded in but not their users and the other way round only an initial attribute is linked.

Does crowd only have the ability to sync one group or is it suppose to sync all of them?

Sync only one group at a time makes no sense, I am just interested to know how people are managing this at the moment in their setups?

Accepted answers

unknown

I managed to resolve this by not using a read-only LDAP option. It seems that when you use the read-only LDAP options it only takes the initial group. This means it only read a group from the directory.

The solution is to ensure that the LDAP section is read-only within JIRA and that it can only ever be edited from within crowd. However, as soon as we set it to the OpenLDAP type of connector and provided the correct information all was well. We were then able to sync all groups associated with the member.

All comments

unknown

Reneesh Kottakkalathil

Hello David,

We had a similar sync issues between jira and crowd. We resolved the issue by using the direct crowd url with port in the user directory section of jira httpd://crowd:8095/crowd. The sync was failing when using the apache reverse proxy url.

Can I ask you another question? Do you have jira groups in your external LDAP? If so how many groups you have created? jira_admin, jira_developers, etc..?

Network Operations team

I figured out a solution around this in the long run.

We have not gone in production with this yet so I cannot fully comment since the environment has been deprovisioned.

We had similar issues, I think we just switch the proxy server to work in a different way. It sounds silly but we were trying to run this on kubernetes, so the main problem was with load balancer configuration.

The groups just need to be nested and mapped properly from LDAP to jira in order for the sync to work.

This seemed to be a type of solution:

"The solution is to ensure that the LDAP section is read-only within JIRA and that it can only ever be edited from within crowd. However, as soon as we set it to the OpenLDAP type of connector and provided the correct information all was well. We were then able to sync all groups associated with the member. "

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-service-desk

crowd