Crowd 2.10 will allow configuring if the group synchronisation is performed when the user logs in.

The options are:

• 'Never' group memberships will never be synchronised on login (this matches the pre-2.7 behaviour that was changed in CWD-3429)
• 'Every time the user logs in' group memberships will always be synchronised on login (this matches 2.8 and 2.9 behaviour)
• 'For newly added users only' group memberships will only be synchronised if the user wasn't synchronised yet via 'normal' synchronisation, and has been created as a part of log in.

On upgrade existing directories will keep their behaviour, new directories will by default use the 'For newly added users only' behaviour.

Recent issues we've had with Crowd are likely traceable directly to this 'feature' overloading our LDAP servers with logins, despite the fact that we have an excellent sync process every 20 minutes. We're in the process of moving off Crowd for Authentication as a result, for as many services as we can manage.

Please make it possible to opt out of direct LDAP queries at login time in favour of hitting the cache.

Our login performance is also quite poor at 20 to 25 seconds. We also use nested groups and can't disable them. We use Active Directory with specific resource permissions groups dedicated to each Confluence space. Our role groups in AD are nested inside these resource permissions groups. This practice makes it easily visible, both inside Confluence and inside AD - which users have permissions to which spaces - and what level of permissions they have. This is highly desirable from a maintainability and security auditing perspective and not something we are willing to give up.

I would also like the ability to disable group sync on login if that is what is causing logins to be so slow. New users tend to be created several days in advance, and we simply trigger a sync manually if we can't wait for the scheduled sync. Slowing down all of our regular user logins to accommodate new users isn't a good trade off from my perspective. I'd rather configure my system for more frequent automatic syncs - which doesn't seem to have a big impact on performance - and make logins faster.

We have been looking for workarounds to improve performance. We recently adjusted our LDAP group filter to read in less groups (avoid reading in resource permissions groups associated with other tools). This made our LDAP syncs faster but didn't improve login performance. Any other suggestions?

eminkevich The reason for the feature is so that an admin can add a user to a group to give that user licensed access to a product, and that user can then immediately log in to that product, rather than having to wait up to an hour before getting their work done.

I agree we should find ways to mitigate and improve the wall clock time it takes to discover and update any group memberships changes this can detect.

I am not sure of the feature usability as well.
With periodic syncs in place why would one need to refresh the groups on logon?

In a situation when multiple and slow Active Directories federated in Crowd it takes some serious time to logon.

Authentication is the #1 feature of Crowd and this regression does affect us a lot. We cannot disable nested groups but we see no meaningful reason for syncing groups on login.

We already have an option for synchronizing the LDAP data using a scheduler / sync cycle so we do not need/want this additional delay. If you are so proud of having this, make it an optional feature, disabled by default and configurable using the properties file.

Improvement? I find quite funny how people are trying to describe bugs as feature requests or improvements. In the end why not dropping the bug concept because any resolution of a Bug could be described as a product Improvement

Because of this now we are seriously considering dropping crowd, for some services or even completely. On a time when we are struggling to improve page load times to keep them under 1s,... we have killer "features" like this one.

In a situation where Crowd server acts as an aggregator for multiple remote ADs the logon time can reach 40 seconds - it seems that Crowd might be checking up the AD's in sequence resulting in a longer delay.

This is expected behaviour. Synching data from LDAP (especially from nested groups) can take a while, and this happens whenever someone logs in. We could improve performance by ignoring nested groups and have them update via the regular sync cycle.