Desktop client locking out Active Directory accounts (New Issue)

[gl1ch]

Expected behaviour

When user changes password in Active Directory the ownCloud client should prompt the user to enter a password after one or two login failures.

Actual behaviour

The ownCloud client repeatedly trys the saved password until the account is locked out. The user then has to know to check the ownCloud client and log out of it (as there is no obvious way to update the password anymore).

Steps to reproduce

1. Change AD password
2. Have the owncloud client running

Server configuration

Operating system: Ubuntu

Web server: Apache

Database: MySQL

PHP version:

ownCloud version: 10.0.10

Storage backend (external storage): Local

Client configuration

Client version: 2.5.4 and newer

Operating system: Windows 10

OS language: English / Japanese

Qt version used by client package (Linux only, see also Settings dialog):

Client package (From ownCloud or distro) (Linux only):

Installation path of client:

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer
logs.

Template for output < 10 lines

1. Client logfile: Output of owncloud --logwindow or owncloud --logfile log.txt
   (On Windows using cmd.exe, you might need to first cd into the ownCloud directory)
   (See also http://doc.owncloud.org/desktop/2.2/troubleshooting.html#client-logfile )

2. Web server error log:

3. Server logfile: ownCloud log (data/owncloud.log):

[ogoffart]

I tested changing my password, and the client only makes two retry to the owncloud server with the old password before asking the user the new password.
The first one is because it thinks the password is correct, and the second one because the auth code does one request to know which authentication we need, and still has the old credentials.
Arguably, the second call is not needed, but still, this should not cause to try too many times.

How many calls does the client do for you?

[gl1ch]

Hi Olivier, Just to make sure are you using LDAP authentication when testing? Not sure if it makes a difference.  So far it hit us with around three to five users. After they changed their password the ownCloud client never popped up asking for the new password and instead kept trying the old password. So within a few minutes the users were locked out. Andrew

[ogoffart]

No, I'm just using the owncloud client with the owncloud server. Looking at the amount of request done from the client to the server.

Maybe there is a problem in the server causing the server not to change the password.
Could be owncloud/core#33853

[gl1ch]

Hi Olivier, To really test you may need to connect it back to an LDAP server. This same issue existed in previous releases so I am wondering if something accidentally was changed back. As for the server. The user can login to the server web site with their correct password as long as they arent locked out by then. I can see the owncloud server relaying the authentication requests to my domain controllers and can see the domain controllers responding saying that the password is bad.

[ogoffart]

I do not have a LDAP setup right now to test.
Is OAuth2 enabled or are users using their login/password from the client?

As I said, in my test, the Client does two request with the previous password before showing the dialog.

Is it maybe because the owncloud server does cache the password as well, ad does not report credentials faillure properly to the client? or does many request to the LDAP server for each client request?

[gl1ch]

Sorry for the late reply. Users are using their direct LDAP user name and password. I dont think the server is caching the password otherwise the saved old password would still work and I probably wouldnt see an LDAP call to my AD servers. Also, I was going to find the exact issue (will try again later) but this same problem has happened before in owncloud a few years ago. There is a closed bug report on it. I am in the middle of something at the moment so didnt have enough time to locate it but as soon as I do I will send it over. Thanks Andrew

[gl1ch]

...and of course after sending the last email I found the issue. Here is the last time this happened: #2186

[TheOneRing]

Nowadays oauth or open id connect is the way to go, basic auth has a low prio for us and isn't recommended in such an scenario.