Issue with LDAP connectivity after upgrading to 7.10


#1

Hi Folks,

Just want to check if anyone has similar issues. After switching to 7.10 from 7.9 we have ongoing issues with users being kicked out from tasklist with the following error:

image

However, we have found that it is happening not with all environments. We were able to trace back this issue to specific LDAP server.

So, did anything like LDAP timeout changed from 7.9 to 7.10? In 7.9 we did not observe those issues with LDAP.

Best regards,
Ilya


#2

Hi Ilya,
I have a similar behaviour in a test environment using a custom identity plugin. On refresh of task list, the error disappears. Thus its not restricted to LDAP. Its as if there is a race condition between authentication and tasklist UI. It does not occur on the native DB identity service…

Until your report, I was thinking it was my custom plugin…

regards

Rob


#3

Hi Rob,

No issues with native DB authentification as well. However, issue is not disappearing when refreshing. Also, after logging in users don’t have a fully qualified name in an upper right corner - only login near home button.

We conducted an experiment early today - switched 4 developers from a “slow” LDAP server to a more powerful one. For two developers problem was fixed and for two others not. I am a bit lost

Best regards,
Ilya


#4

Hi @Webcyberrob!

We did additional analysis for this issue today. So the issue is solely with a tasklist application. If you log in through cockpit or a welcome screen - you would be able to login to tasklist afterwards. However, users cannot login directly to a tasklist. I believe that tasklist has an aggressive tolerance limit / latency threshold configured in 7.10.

Could anyone from Camunda team please comment on:

  • How to change LDAP response latency threshold in web apps, especially tasklist?
  • What has changed in LDAP config since 7.9?

Thank you in advance

Best regards,
Ilya


#5

Hi Ilya,

We didn’t change LDAP configuration since 7.9.
When the problem occurs could you please collect some traces:

  • console log from dev tools
  • complete stack trace of an exception if there’s any in server log file

Best regards,
Yana