-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow login after change ldap password #3762
Comments
Update: it is now working ok after running a system update and rebooting the server. ¯\_(ツ)_/¯ I'd still be interested to know why it does this though - it's the second time I've had the issue, and now both times it's mysteriously resolved itself. |
could be related to the brute force detection somehow. |
cc @nextcloud/ldap |
I also think brute force detection kicked in. Would be the case if there were any clients from the same network (IP) trying to access Nc with the old password. Likely, @swalladge ? |
@blizzz yep that is most likely. Are there docs explaining the behaviour of the brute force protection? Either way it's not very user friendly if this happens on local networks every time someone changes their password. |
Every LDAP implementation is not user friendly :( Maybe there is some workaround? |
Well, this is not specific to LDAP, but would happen with the local backend or any other user backend as well. Then however, perhaps you could add some logic that prevents brute force protection to kick in for an hour or so, when the password is changed. However, we can only now internally about this event, not from other systems like the LDAP server. You could advise your users to use app/device passwords for clients or machines instead (this can be enforced for non-website auth when you enable TOTP, while then the web interface will ask for a one-time token). Of course this adds some overhead and work for users, but then the LDAP password change would effect web interface login only. About the brute force protection:
Another point is that the ideal client would recognize that authentication failed (not that the server is offline or has other issues) and asks for entering the password. If enough people share the same IP (proxy?) it won't make a difference though. |
For expired passwords, the #1023 enhancement might be helpful in this regard, at least for OpenLDAP users. Users would be notified when their password is about to expire, and with grace logins allowed, an active session wouldn't be oddly interrupted on expiry, and for new sessions, users with expired passwords are instructed to renew their password during login. |
After a discussion with @LukasReschke yesterday it's also worthwhile to think about deleting brute force attempts from the DB after a successful login from within the IP. This requires frequent DB access (at least another read per login on success). |
It would be nice to have a way to view the status of brute force protection from the admin panel - history of brute force attempts, whether it is currently active, and button to reset it. |
#7263 resets the brute force attempts on successful login → closing |
Steps to reproduce
Expected behaviour
Changing an ldap user's password should only affect nextcloud in that you need to login with your new password.
Actual behaviour
The new password is accepted, but login to the web interface takes ~30 seconds, and other apps such as the desktop sync client or mobile apps error out with timeouts.
Currently the desktop sync client is showing "No connection to Nextcloud at . Operation cancelled."
Server configuration
Operating system: Archlinux
Web server: Nginx
Database: MariaDB
PHP version: 7.1.1
Nextcloud version: 11.0.2
Updated from an older Nextcloud/ownCloud or fresh install: Updated from 11.0.1 (which in turn was updated from 11.0.0)
Where did you install Nextcloud from:
Signing status:
Signing status
List of activated apps:
App list
(however, it was slow even after updating to 11.0.2, where it automatically disables all extra apps)
The content of config/config.php:
Config report
Are you using external storage, if yes which one: smb
Are you using encryption: no
Are you using an external user-backend, if yes which one: LDAP
LDAP configuration (delete this part if not used)
LDAP config
Client configuration
Browser: Chromium, and all others tested
Operating system: Archlinux, Android
Logs
Web server error log
Web server error log
Nextcloud log (data/nextcloud.log)
Nextcloud log
(I'm guessing the bind failed is from some app still trying to login with the old password, even though I'm sure I updated them all.)
Also I tried turning off the bruteforce protection setting, to no avail.
The text was updated successfully, but these errors were encountered: