-
Bug
-
Resolution: Fixed
-
Medium (View bug fix roadmap)
-
4.4.3, 5.1.6, 5.2.1, 6.0, 6.0.5, 6.1.2
-
4.04
-
Summary
We have our Jira instance setup to synchronize with Active Directory such that any users that are added to a particular AD group are supposed to automatically become Jira users. When we initially configured the user directory, the synchronization worked perfectly and all users were able to login to Jira. However, when a new user joined the AD group, it is not automatically created in JIRA.
Steps to Reproduce
The following LDAP User Filter is used on the User Directory:
"ldap.user.filter": "(&(objectCategory=Person)(memberOf=CN=newgrp,CN=Users,DC=company,DC=local))"
Expected Results
All the users that are members of the newgrp after the synchronization are automatically added to the jira-users group.
Actual Results
For the first time the directory is synchronized, everything works fine. However, if a user is added to the newgrp directory after the first synchronization, it is not automatically added to Jira, instead we can see this message in the atlassian-jira.log:
2011-12-06 10:05:41,016 QuartzWorker-1 WARN ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] Could not add the following missing users to group [ newgrp ]: [johndoe]
Workaround
The workaround for this situation is to go into your Advanced Settings in your user Directory and uncheck "Enable Incremental Synchronization" as per Connecting to an LDAP Directory.
- has a derivative of
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- is caused by
-
-
- Closed
-
- is related to
-
-
- Closed
-
- mentioned in
-
Page Loading...
-
-
-
-
-
[JRASERVER-26458] Synchronization of users that are added to a particular AD group that is configured to automatically become JIRA users doesn't work after the initial synch
Incremental AD sync now performs a diff on objectGUIDs present in remote and cached directory in addition to scanning the usnChanged attribute.
This way it's possible to find users to be removed, updated and added in a reliable manner.
The correctness of incremental sync comes at a price of slightly worse performance and increased memory consumption - still it's better than running a full sync.
It runs in approximately 10%-15% time of full sync depending on the volume of changes.
It is possible to switch back to 'legacy' incremental AD sync by supplying a system property crowd.use.legacy.ad.incremental.sync set to true.
This is a extremly critical issue for us. We are syncing 4 (AD) "User Directories" to put different groups of people in different jira user groups. The Full Synchronization causes a huge heap (10GB) and cpu usage (550% of 6 core's) on our environment as it synchronizes everytime more than 38000 users. Also it seems that the "Synchronization Intervall" option does not work as it synchronizes earlier than it should.
We would be glad if you could fix it in 6.2 as we need to stay on this version because of IE8 support from Atlassian.
Described symptoms and message in logs like:
2011-12-06 10:05:41,016 QuartzWorker-1 WARN ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] Could not add the following missing users to group [ newgrp ]: [johndoe]
can appear because of several different reasons. Most of them are related to one or more of this operations:
- using additional user filters
- deleting user and creating new user with same name
- renaming user and creating new user with same name
- network/disk/database problems during synchronization
Fix related to first one can be tracked here: CWD-3943.
Fix related to second one can be tracked here: CWD-3955. This one is already solved and should be available in JIRA soon.
Remaining two will possibly be solved during fixing CWD-3943, if not separate tickets for tracking them will be provided.
Tim Schaller
added a comment - Getting this issue when working with OpenLDAP
user DN is formatted like: uid=tim,ou=People,dc=mydomain,dc=com
In the group the full DN is specified in the memberUid field.
As a work around I can add the user with just the uid in the memberUid field (not the full user DN)
memberUid: tim
memberUid: sally... etc
While this is workable on a small scale, it fails to be viable on a large scale.
Tim Schaller
added a comment - Getting this issue when working with OpenLDAP
user DN is formatted like: uid=tim,ou=People,dc=mydomain,dc=com
In the group the full DN is specified in the memberUid field.
As a work around I can add the user with just the uid in the memberUid field (not the full user DN)
memberUid: tim
memberUid: sally... etc
While this is workable on a small scale, it fails to be viable on a large scale. I'm noting this issue when working with eDirectory as an ldap source. Unfortunately the workaround isn't available as it doesn't have the incremental sync as an option.
It doesn't have fix version yet because it has not been scheduled for an upcoming maintenance release. As soon as that happens I will make sure the version information is available.
Please watch the issue for further updates, I will update it as soon as more information is available.
Regards,
Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].
Intel CHD Jira Admin
added a comment - Why is this major bug not assigned a fix version yet?
-David We have found that the workaround for this doesn't work in JIRA 6.1.5 using LDAP sync. I have to restart JIRA so that the cache gets dropped, then the new users will synchronize. It seems that something could be written into the directory management to force this cache to be deleted by simply stopping and starting the directory while logged in from an account outside the directory.
We need this fix in 6.3.5!