Desktop client causing Active Directory account lockouts

[techjordan]

Expected behaviour

The user's AD password is changed and the client prompts for the updated password. If the client is left without updating the password the AD account remains unlocked.

Actual behaviour

The user's AD password is changed but the client does not prompt for the updated password. The client indicates that the credentials are incorrect and the AD account becomes locked. The AD account remains unlocked once the client is not running. Rolling back to version 1.6.0 stopped the lockouts.

Steps to reproduce

1. Exit the client
2. Unlock the AD account
3. Load the client

Server configuration

Operating system: Server 2008 R2 SP1

Web server: IIS 7.5

Database: mySQL 5.5.30

PHP version: 5.3.18

ownCloud version: 4.5.7

Storage backend: SAN

Client configuration

Client version: 1.6.3

Operating system: Windows 8

OS language: English

Installation path of client: default

Logs

[cabillman]

I have been noticing this behavior on machines that were running 1.5.x versions of the client and upgraded directly to 1.6.3.

The client is not prompting for the credentials when the authentication fails. It repeatedly tries an incorrect password triggering AD to lock the account.

Could it be related to this commit? 88f26fb

[techjordan]

Is there anything further on this? I'm now forced to freeze my clients on 1.6.0 until the problem doesn't occur on newer versions.

cabillman, I will have to try doing an upgrade from a 1.5.X client to see if the problem occurs.

[Thalagyrt]

I just spent about 3 hours hunting down why I was getting locked out, only to find it was the ownCloud client on my desktop. This needs to be fixed. When authentication fails, trying to reauthenticate every 30 seconds is NOT acceptable behavior.

[alesupper]

I have the same issue, except my clients are trying to re-authenticate every 100ms or so, which is hogging the cpu on the server.

[alesupper]

I am getting the following messages in owncloud.log several times every second and it is hogging the server cpu:-

{"app":"user_ldap","message":"Bind failed: 49: Invalid credentials","level":3,"time":"2014-10-16T14:39:08+00:00"}

I am also getting the following messages in /var/log/apache2/ssl_access.log several times per second:-

client-ipaddress - username [16/Oct/2014:15:38:21 +0100] "GET /owncloud/status.php HTTP/1.1" 200 1172 "-" "Mozilla/5.0 (Windows) mirall/1.6.3"
client-ipaddress - username [16/Oct/2014:15:38:21 +0100] "PROPFIND /owncloud/remote.php/webdav/ HTTP/1.1" 401 1200 "-" "Mozilla/5.0 (Windows) mirall/1.6.3"

[techjordan]

I've been doing some testing and so far it seems to be happening mostly (not completely) in Windows 8 for some reason. Cannot duplicate it consistently which is quite frustrating.

I ended up compiling my own 1.6.0 in order to prevent it from being auto-updated once its installed.

[alesupper]

All our clients are Windows 7.

[tomswartz07]

This is a pretty big issue for large deployments. With the number of security patches between known-working versions (1.5?) to 1.6.3, it's not ideal to keep clients on an older version.

Any suggestions about a fix?
c/c @danimo

[alesupper]

Yes its certainly a big issue for us, as it keeps crippling our server's cpu.

[techjordan]

After all the various challenges I've experienced with this product, though being a wonderful idea, I'm beginning to think I'm going to need a different solution. Extremely high maintenance!

[cabillman]

I have been able to reliably reproduce this by installing an old version of the client first.

1. Install 1.4.x of the client and configure it
2. Update to 1.6.x
3. Change password

Instead of prompting for a new password the client continually tries the old credentials. In Active Directory envionments this will trigger an account lockout.

I removed the old credentials from the regitsy (Owncloud/OrganizationDefaults/username:https:) and was immedietly prompted for a password by the client.

It still looks to me like this change 88f26fb could be the cause but I don't have a build environment setup to test/build a patch.

[tomswartz07]

As mentioned by @cabillman and others, we can verify that the libcsync/creds/httpcredentials.cpp will continuously check the old value from the old location.

Looking here at the code for the http credentials, the highlighted section in the link seems to be the culprit when tied to the HttpCredentials::fetch function.

The loop would appear to be as follows:

1. Attempt to fetch credentials
2. Credentials are incorrect, check DepreciatedPlace
3. DepreciatedPlace has wrong credentials, but job->setKey(kck); tries to connect anyway
4. Attempt to log in and fail, repeat; never getting to _readPwdFromDeprecatedPlace = false;

I think moving the contents of Line 281 to above the ReadPasswordJob commands (Line 273) might prevent the loop, but I don't have a build system set up to compile and test.

Note the comment indicated in the highlighted section linked above:

// Note: if this read job succeeds, the value from the old place is still
// NOT persisted into the new account.

This is fine and dandy if it works, but I would suggest adding a bit more logic to the function to remove the old value from the old location if it's no longer valid.
If it's depreciated, not used by the client, and no longer valid, why keep it around? 😄

---

For the time being, my organization has simply gone through and administratively removed the old registry key with a scripted policy to solve the issue, but it might be more useful to have the client be a good citizen and clean up after itself.
@techjordan @alesupper : I'm not sure if you've been able to resolve the issue on your machines, but removing that registry key will fix it.

[kiritoShift]

Hi,
I've experienced the same issue iOS client.
i've more than 150 users, and they're using iOS,Windows, and mac client.
For now we have been able to avoid the issue by disabling the automatic lock on our AD.
This is not safe for us, and makes our domain vulnerable.

(PS: sry for my english)
best regards.

[plrunner]

This bug affects also the client v1.7 (am on Windows 7).
I have worked around the problem by making the user

• close the client
• remove the conf file under the AppData\Local\Owncloud\ folder
• re-open the client and enter the server data and credentials again
  PL

[guruz]

@ckamm This issue is a reason to not re-try auth (ckamm@194ace7) and just show the dialog (ckamm@cc4c40d)

[ckamm]

This has several conflicting points of view:

1. The account locks after a couple of failed webdav queries with wrong password, please never retry if auth failed!

2. Sometimes the LDAP auth backend restarts and authed requests fail, please don't bother our users about it! On authentication failure do not pop up Password dialog #2848

3. The client does many parallel requests during sync.

4. and 2) obviously conflict.

5. and 3) also conflict, because if the AD password changed during a sync it's likely that we'd query the server with several parallel requests using the old password before getting the first 'auth failed' reply back, locking the account.

The only reasonable solution I can see right now is having a separate, explicit authentication request that results in a session cookie the client can use for further requests. Effectively logging in anew with each request just can't work with 1).

@PVince81 I don't know much about authentication in the server, is there a way we could do it with the existing API?

[guruz]

3. The client does many parallel requests during sync.

IMHO we need to remove the user:password base64 from the WebDAV requests, then only the session cookie is used (which does not do any re-login by itself). Then only checkServerAndAuth (or whatever it is called) does actual authentication.

[danimo]

@guruz Too much speculation here, the last time we checked this, the session took precedence. Let's analyze this today.

[ckamm]

We talked about the issue in detail. Currently each request usually has a session cookie as well as the user and password. So each request could be considered a possible login. But the user/pw will only be used if the session cookie is invalid. That means this ticket is probably not due to parallel request with outdated credentials.

I've looked at @tomswartz07's comment and implemented a fix for deleting the old registry key in 6b1ba78 that will likely end up in 1.8.1.

Could anyone experience account lockouts that were unrelated to upgrading from old owncloud clients?

[guruz]

IMHO we need to remove the user:password base64 from the WebDAV requests, then only the session cookie is used

For the record @ogoffart has done this for 2.0 ae17f58

[moscicki]

For the root cause of this problem: isn't this the owncloud server problem/limitation that it tries to authenticate against AD too often with the basic auth instead of properly caching this for some time (as for the cookies)? And if the owncloud server notices that they can implement a policy of not trying to contact AD with invalid password.

As per removing basic authentication: unfortunately this change breaks cernbox as our server does not support cookie authentication. I don't think this works for us now and I do not know if this ever will.

[Dianafg76]

I tested the issue, and the password is change and the password the AD account is not unlocked.
Desktop v1.8.2 (build 2362)
So I close the Issue