After AD password change, SonarQube repeated "infinite" failed LDAP auth attempts

  • SonarQube version 8.9.1 w/LDAP
  • User LDAP auth attempts fail with incorrect password, but user is not even trying to log in; these are automated, recurring attempts.
  • How can I get SonarQube to stop infinite auth attempts for this user OR fix the user’s auth in SonarQube so the auth is successful (which presumably would stop the constant attempts).
  • I’ve restarted SonarQube app docker container, rebooted the VM; no effect; the auth attempts for this user recur, several times per minute.
  • My workaround (since these failed LDAP auth attempts by SonarQube were constantly locking the user’s AD account) was to de-activate the users’s account in SonarQube web UI. Even that did not resolve the problem; the auth attempts contined, even after restarting the container. I had to then re-create the user with same name as a LOCAL user. Now the auth-attempts several times per minute continue, but at least they don’t hit our AD server.
  • I’m worried this problem could spread to other users. If it does, it will quickly become unmanageable. It could also affect server/app performance.
  • I’ve not been able to find any relevant cache to clear, or mechanism that is scheduling these auth attempts.
  • Turning log level to DEBUG and TRACE did not provide any more useful info as to why these attempts happen or how to stop them.
  • Perhaps there is some way to remove these from the database?


Welcome to the community!

I’m not aware of anything within SonarQube that would cause these auth attempts to fire, and particularly not at that rate. Can you check $SONARQUBE-HOME/logs/access.log to see if SonarQube’s receiving requests to cause this?


Thanks, ganncamp! We don’t have access.log, but I could see the attempts by using commands like docker logs --since 10m -f sonarqube_sonarqube_1 | grep <username> and docker logs --since 10m -f reverse_proxy | grep <username>

However, I just restarted the docker containers (sonarqube_sonarqube_1 and reverse_proxy which is nginx) on our DEV and COMMON/PROD VMs AGAIN, and NOW the attempts have stopped.

Either there was some residual processes playing out the last time I tested, or someone or some process has cleaned something up.

BTW, previously, the logs were showing the attempts were coming from a local docker IP, not a remote host.

I think the next step is for me to try to re-create the user as an AD/LDAP user, and hope the problem does not recur.

I think to do this, I must deactivate the local user, add sonar.authenticator.createUsers: true to the SonarQube config and restart the container so that it will create an AD/LDAP user the first time the user logs in.

1 Like

Hey there.

sonar.authenticator.createUsers has not had any impact since SonarQube v6.3. Deactivating the user should be sufficient.

1 Like

Oh, that’s nice. Thank you, Colin.