LDAP authentication

[Bran-Ko]

I using local owncloud and LDAP authentization. But every time when I update/reboot LDAP server local client (on windows) wants login. Restart of sever took 10-20sec - I mean that client is very sensitive. Can you extend this time for connect LDAP ? Or is it possible to configure it on server ?

[dragotin]

@blizzz do you understand whats going on here?

[blizzz]

@dragotin i assume the client wants to authenticate, but the LDAP server is down so it does not succeed and subsequently the client cries for a new password.

[dragotin]

So what happens is that the server can not validate the password against the LDAP and thus it returns 401 to the client? Why doesn't it use the session header? @blizzz

[blizzz]

@dragotin most likely, with LDAP being offline user existence cannot be verified.

[DeepDiver1975]

@Bran-Ko which server version are you using?

@LukasReschke afaik for oc8 we did change the cookie/basic auth validation. Background the client is always sending basic auth headers and cookies - this might lead to the effect that the session is not reused????

[DeepDiver1975]

just another reason why we should move away from the cookie and basic auth kung-fu - long live OAuthy-Fu

[LukasReschke]

@LukasReschke afaik for oc8 we did change the cookie/basic auth validation. Background the client is always sending basic auth headers and cookies - this might lead to the effect that the session is not reused????

I did some tests locally, though not connected to a LDAP server. If both, a valid cookie, as well as a basic auth header is provided the server will prefer the cookie and not request a reauthentication.

My best guess here is that \OC_User::isLoggedIn is calling \OC_User::userExists which then returns false since we can't lookup the user as we don't store them in the database 🙈

[LukasReschke]

Code path:

https://github.com/owncloud/core/blob/299bcf749a63efa6516afeb3e826f087a31187e9/lib/private/connector/sabre/auth.php#L54-54
https://github.com/owncloud/core/blob/299bcf749a63efa6516afeb3e826f087a31187e9/lib/private/user.php#L349-349

[blizzz]

My best guess here is that \OC_User::isLoggedIn is calling \OC_User::userExists which then returns false since we can't lookup the user as we don't store them in the database 🙈

No, that's not the problem, we have them in the mappings table. The thing is, that we would have it there, even if the user was removed or disabled in LDAP.

[waspinator]

I have a similar issue.

Background:
Users are managed with Active Directory (Windows 2012R2), and connected to ownCloud using LDAP. The AD server, as well as the ownCloud server are running on ESXi 5.1 and are backed up using Veeam every 24 hours. A snapshot is made of each sever before backing up, and each server may become unresponsive for ~10 minutes during that time due to hardware limitations.

Once LDAP goes down the ownCloud client forgets the last used password. Then when LDAP is available again it asks the user to enter their password. Ideally the client should retry the connection with the saved password before asking the user for a new one.

Environment: Debian 7.5 (root vps)
Server: Apache/2.2.22 (Debian)
Database: mysql Ver 14.14 Distrib 5.5.41, for debian-linux-gnu (x86_64) using readline 6.2
Client: 1.7.1 (4382)
OC-Version: 8.0.2
PHP-Version: PHP 5.4.4.14+deb7u12

[guruz]

@waspinator But then how to know how long to retry with the saved password? For you it is 10 minutes (vs 10 secs for @Bran-Ko) , but what if the user actually changed their password in AD but the oC client does not prompt for the password?

[guruz]

@DeepDiver1975 @LukasReschke @blizzz Is there a way for the oC auth plugin to return HTTP 500 or so for WebDAV if it is configured to use LDAP?
(The normal webinterface obviously needs to fall back to the integrated oC accounts for the admin account)

[blizzz]

@guruz you may show the dialogue, but keep it filled wiht the known password.

Currently there is nothing foreseen to create a 500 or something else in this scenario.

[ckamm]

@blizzz @guruz @Bran-Ko Was this ticket resolved to your satisfaction by pre-filling the password with the old one? :)

I think this ticket can be closed, further work on auth-error treatment is discussed in #2848.

[Bran-Ko]

Sorry I was outside... But I think it will be sufficient