LDAP over-authenticating after upgrade UPDATED/Simplified #26065

PaulHughes99 · 2016-09-08T10:51:26Z

After upgrading OC Server (from 9.0.0.19 to 9.1.0.15) , a previously working LDAP setup is broken; LDAP is now making at least three authentication calls (binds with user password) each time a client logs in through webinterface, and frequent unwanted authentications from the desktop client (previously it was only one authentication when the client booted up).
(NB This matters because I've successfully implemented 2-factor authentication onto the LDAP server, so too many authentications causes total chaos) This is a very severe issue.
My question is whether the LDAP coding in OC has changed; and is there way to prevent these multiple authentications?
I've noted topic: https://central.owncloud.org/t/lot-of-ldap-traffic/19091 which may have similar cause.
This is my first post , so apologies if i've not provided some relevant info.

Steps to reproduce

install OC server & an LDAP server (e.g. OpenLDAP)
login to OC server as a user via web interface
check log of LDAP server to see multiple bindings for single login. (Not sure how to see that on OC's own log)

Expected behaviour

OC should perform a single authentication on LOGIN, and thereafter cache shoudl prevent further authentications being necessary; the OC desktop client should authenticate only once at startup.

The LDAP log from working Owncloud 9.0 server (grep -R slapd /var/log/syslog) shows a single search for the user's UID -- in this case 'ttest' followed within the same connection by a successful bind with the full DN 'test test' etc, and password.

SRCH base="dc=so*********_" scope=2 deref=0 filter="(&(|(objectClass=inetOrgPerson))(|(uid=ttest)(|(?mailPrimaryAddress=ttest)(mail=ttest))))"
...
BIND dn="cn=test test',ou=users,dc=so**_******_" method=128
BIND dn="cn=test test',ou=users,dc=so**_*******" mech=SIMPLE ssf=0

###Actual behaviour

in OC 9.1, the LDAP server is being asked to search THREE times for the user name, and the username plus password is authenticated THREE times.

 _(search1)_
SRCH base="dc=so******_**t" scope=2 deref=0 filter="(&(|(objectClass=inetOrgPerson))(uid__=ttest)__)"
 ...
BIND dn="cn=__test test__,ou=users,dc=so_*****_**t" method=128
BIND dn="cn=__test test__,ou=users,dc=so_*******_t" mech=SIMPLE ssf=0
 ..

_(search2)_
SRCH base="dc=so**_***_**t" scope=2 deref=0 filter="(&(|(objectClass=inetOrgPerson))(uid=__ttest__))"
 ..
BIND dn="cn=__test test__,ou=users,dc=so_*****_**t" method=128
BIND dn="cn__=test test,__ou=users,dc=so_********t" mech=SIMPLE ssf=0

_(search3)_
SRCH base="dc=so******_**t" scope=2 deref=0 filter="(&(|(objectClass=inetOrgPerson))(uid=__ttest)_*)"
 ..
BIND dn="cn=**test test**,ou=users,dc=so******_**t" method=128
BIND dn="cn=__test test__,ou=users,dc=so_********t" mech=SIMPLE ssf=0

Server configuration

Operating system: Ubuntu
Web server: Apache/2.4.7 (Ubuntu)
Database: MySQL
PHP version: PHP 5.5.9-1ubuntu4.19 (cli) (built: Jul 28 2016 19:31:33)
ownCloud version (see ownCloud admin page): ownCloud 9.1.0 (stable)
Updated from an older ownCloud or fresh install: updated
ownCloud log (data/owncloud.log, see https://central.owncloud.org/t/how-to-find-webserver-or-oc-logfile-enable-php-logfile/808):

Special configuration (external storage, external authentication, reverse proxy, server-side-encryption):

Integrity status for oC9+

Login as admin user into your ownCloud and access
http://example.com/index.php/settings/integrity/failed
paste the results here.
No errors have been found.

{
    "system": {
        "updatechecker": false,
        "instanceid": "oci9*****",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "****",
            "****t"
        ],
        "datadirectory": "\/var\/www\/owncloud\/data",
        "overwrite.cli.url": "http:\/\/****\/owncloud",
        "dbtype": "sqlite3",
        "version": "9.1.0.15",
        "logtimezone": "UTC",
        "installed": true,
        "ldapIgnoreNamingRules": false,
        "mail_smtpmode": "smtp",
        "mail_from_address": "***",
        "mail_domain": "****",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtphost": "smtp.***.com",
        "mail_smtpport": "**",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "ssl",
        "loglevel": 0,
        "maintenance": false
    }
}

LDAP configuration (delete this part if not used)


+-------------------------------+---------------------------------------------------------------------------------------+
| Configuration                 |                                                                                       |
+-------------------------------+---------------------------------------------------------------------------------------+
| hasMemberOfFilterSupport      |                                                                                       |
| hasPagedResultSupport         |                                                                                       |
| homeFolderNamingRule          |                                                                                       |
| lastJpegPhotoLookup           | 0                                                                                     |
| ldapAgentName                 | uid=user******\*                                                                      |
| ldapAgentPassword             | **\*                                                                                  |
| ldapAttributesForGroupSearch  |                                                                                       |
| ldapAttributesForUserSearch   |                                                                                       |
| ldapBackupHost                |                                                                                       |
| ldapBackupPort                |                                                                                       |
| ldapBase                      | dc=so******\*                                                                         |
| ldapBaseGroups                | dc=so******\*                                                                         |
| ldapBaseUsers                 | dc=so******\*                                                                         |
| ldapCacheTTL                  | 600                                                                                   |
| ldapConfigurationActive       | 1                                                                                     |
| ldapDynamicGroupMemberURL     |                                                                                       |
| ldapEmailAttribute            | mail                                                                                  |
| ldapExperiencedAdmin          | 0                                                                                     |
| ldapExpertUUIDGroupAttr       |                                                                                       |
| ldapExpertUUIDUserAttr        |                                                                                       |
| ldapExpertUsernameAttr        |                                                                                       |
| ldapGroupDisplayName          | cn                                                                                    |
| ldapGroupFilter               |                                                                                       |
| ldapGroupFilterGroups         |                                                                                       |
| ldapGroupFilterMode           | 0                                                                                     |
| ldapGroupFilterObjectclass    |                                                                                       |
| ldapGroupMemberAssocAttr      | uniqueMember                                                                          |
| ldapHost                      | 127.0.0.1                                                                             |
| ldapIgnoreNamingRules         |                                                                                       |
| ldapLoginFilter               | (&(|(objectclass=inetOrgPerson))(|(uid=%uid)(|(mailPrimaryAddress=%uid)(mail=%uid)))) |
| ldapLoginFilterAttributes     |                                                                                       |
| ldapLoginFilterEmail          | 1                                                                                     |
| ldapLoginFilterMode           | 0                                                                                     |
| ldapLoginFilterUsername       | 1                                                                                     |
| ldapNestedGroups              | 0                                                                                     |
| ldapOverrideMainServer        |                                                                                       |
| ldapPagingSize                | 500                                                                                   |
| ldapPort                      | 389                                                                                   |
| ldapQuotaAttribute            |                                                                                       |
| ldapQuotaDefault              |                                                                                       |
| ldapTLS                       | 0                                                                                     |
| ldapUserDisplayName           | cn                                                                                    |
| ldapUserDisplayName2          |                                                                                       |
| ldapUserFilter                | (|(objectclass=inetOrgPerson))                                                        |
| ldapUserFilterGroups          |                                                                                       |
| ldapUserFilterMode            | 0                                                                                     |
| ldapUserFilterObjectclass     | inetOrgPerson                                                                         |
| ldapUuidGroupAttribute        | auto                                                                                  |
| ldapUuidUserAttribute         | auto                                                                                  |
| turnOffCertCheck              | 0                                                                                     |
| useMemberOfToDetectMembership | 1                                                                                     |
+-------------------------------+---------------------------------------------------------------------------------------+

The text was updated successfully, but these errors were encountered:

PaulHughes99 · 2016-09-14T09:41:18Z

I've checked previous working configuration Owncloud 9.0.0.19 ; this appears like a major bug in LDAP in the new version.

PVince81 · 2016-10-06T06:35:24Z

@owncloud/ldap

PVince81 · 2016-10-06T06:37:05Z

Since 9.1 there is some new logic that will try and detect whether a LDAP user still exists by doing a bind with the user password. Maybe that check is running too early and causes additional needless calls.

PaulHughes99 · 2016-10-06T19:26:25Z

Thanks for your response - happy to assist with any test to nail this issue.

PVince81 · 2016-10-20T10:24:27Z

Maybe we need a config switch, also on the LDAP wizard, to disable such checks...

@jvillafanez what do you think ?

PVince81 · 2016-11-09T10:57:18Z

You could try to increase the value from 60 * 5 to 3600 * 24 to have the check only done once a day: https://github.com/owncloud/core/blob/v9.1.2/lib/private/User/Session.php#L571

Then see if it help reduce the over-authentication.

We should make that value configurable and if the value is "0" or "-1", disable the check altogether.

jvillafanez · 2016-11-17T13:54:58Z

The only code piece that could be over-authenticating in the LDAP code should be https://github.com/owncloud/core/blob/stable9.1/apps/user_ldap/lib/User_LDAP.php#L137 . Probably core is checking too many times the password.

felixboehm · 2016-12-20T21:28:56Z

Any progress here? @butonic

PVince81 · 2017-01-11T16:00:05Z

@PaulHughes99 did you try with my advice from #26065 (comment) ?

PVince81 · 2017-01-19T16:57:51Z

Please also make sure you have memcache enabled to reduce the number of queries to LDAP.

PVince81 · 2017-01-19T16:58:17Z

cc @cdamken

PaulHughes99 · 2017-01-19T17:50:39Z

Hi - sorry i was distracted by other projects but will look at this again in next few days. Sent from a phone.

…

On 19 Jan 2017, at 16:58, Vincent Petry ***@***.***> wrote: Please also make sure you have memcache enabled to reduce the number of queries to LDAP. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

PaulHughes99 · 2017-01-23T10:52:58Z

@PVince81 I will devote some time to this now but please forgive a couple of newby questions:
a) To test code modifications, I simply directly modify the Session.php file on my test OC instance, and then relaunch?
b) Where do i enable memcache?

PVince81 · 2017-01-23T11:58:03Z

@PaulHughes99 in this specific case, yes. Directly modify Session.php.
For memcache, see config.sample.php or the admin documentation https://doc.owncloud.org/server/9.1/admin_manual/

PaulHughes99 · 2017-01-23T14:45:03Z

@PVince81 Thanks. I've made those changes and it does appear to reduce the over-authentication. I'll test it though over a couple of days and report back.

PaulHughes99 · 2017-01-24T16:26:57Z

So, once logged in, the authentication ceases, so adjusting this variable certainly helps. However, it is still over-authenticating (2-3) times during log-in process, both from web log-in and from desktop app. I'm wondering if there is a timeout parameters somewhere which is performing multiple re-tries because the response from the LDAP server is too slow. I'll hunt through the code, but if you know where to look please tell me.

PaulHughes99 · 2017-01-27T23:05:45Z

@PVince81 @jvillafanez OK I've narrowed things a little. There are two things that could be wrong here.
This code https://github.com/owncloud/core/blob/v9.1.2/lib/private/User/Session.php#L571 authenticates every 5 minutes, as you suggested; I realise that is deliberate and the problem i have with it is solvable by changing the value.
But, in addition, extra presumably unintended authentications also occur on initial login (presumably the login without token): I can see from logs the password is being checked three times instead of once. I've looked at the code but can't figure why. I've verified this does not occur in the previous release, where the password is checked a single time.

fredreichbier · 2017-06-30T06:20:02Z

Hi there! As @cornelinux already mentioned, we see three bind requests per user login in owncloud 10.0.2 with the user_ldap app 0.9.1.

If it helps, here are the backtraces for the three invocations of OCA\User_LDAP\Connection->bind() (excluding the recurring bind requests every 5 minutes):

#0 /var/www/owncloud/apps/user_ldap/lib/Connection.php(608): OCA\User_LDAP\LDAP->bind(Resource id #86, 'uid=user777,cn=...', 'password777')
#1 /var/www/owncloud/apps/user_ldap/lib/Access.php(1411): OCA\User_LDAP\Connection->bind()
#2 /var/www/owncloud/apps/user_ldap/lib/User_LDAP.php(134): OCA\User_LDAP\Access->areCredentialsValid('uid=user777,cn=...', 'password777')
#3 [internal function]: OCA\User_LDAP\User_LDAP->checkPassword('user777', 'password777')
#4 /var/www/owncloud/apps/user_ldap/lib/User_Proxy.php(79): call_user_func_array(Array, Array)
#5 /var/www/owncloud/apps/user_ldap/lib/Proxy.php(140): OCA\User_LDAP\User_Proxy->walkBackends('user777', 'checkPassword', Array)
#6 /var/www/owncloud/apps/user_ldap/lib/User_Proxy.php(194): OCA\User_LDAP\Proxy->handleRequest('user777', 'checkPassword', Array)
#7 /var/www/owncloud/lib/private/User/Manager.php(215): OCA\User_LDAP\User_Proxy->checkPassword('user777', 'password777')
#8 /var/www/owncloud/core/Controller/LoginController.php(186): OC\User\Manager->checkPassword('user777', 'password777')
#9 [internal function]: OC\Core\Controller\LoginController->tryLogin('user777', 'password777', NULL)
#10 /var/www/owncloud/lib/private/AppFramework/Http/Dispatcher.php(159): call_user_func_array(Array, Array)
#11 /var/www/owncloud/lib/private/AppFramework/Http/Dispatcher.php(89): OC\AppFramework\Http\Dispatcher->executeController(Object(OC\Core\Controller\LoginController), 'tryLogin')
#12 /var/www/owncloud/lib/private/AppFramework/App.php(98): OC\AppFramework\Http\Dispatcher->dispatch(Object(OC\Core\Controller\LoginController), 'tryLogin')
#13 /var/www/owncloud/lib/private/AppFramework/Routing/RouteActionHandler.php(46): OC\AppFramework\App::main('LoginController', 'tryLogin', Object(OC\AppFramework\DependencyInjection\DIContainer), Array)
#14 [internal function]: OC\AppFramework\Routing\RouteActionHandler->__invoke(Array)
#15 /var/www/owncloud/lib/private/Route/Router.php(299): call_user_func(Object(OC\AppFramework\Routing\RouteActionHandler), Array)
#16 /var/www/owncloud/lib/base.php(918): OC\Route\Router->match('/login')
#17 /var/www/owncloud/index.php(49): OC::handleRequest()
#18 {main}

#0 /var/www/owncloud/apps/user_ldap/lib/Connection.php(608): OCA\User_LDAP\LDAP->bind(Resource id #89, 'uid=user777,cn=...', 'password777')
#1 /var/www/owncloud/apps/user_ldap/lib/Access.php(1411): OCA\User_LDAP\Connection->bind()
#2 /var/www/owncloud/apps/user_ldap/lib/User_LDAP.php(134): OCA\User_LDAP\Access->areCredentialsValid('uid=user777,cn=...', 'password777')
#3 [internal function]: OCA\User_LDAP\User_LDAP->checkPassword('user777', 'password777')
#4 /var/www/owncloud/apps/user_ldap/lib/User_Proxy.php(106): call_user_func_array(Array, Array)
#5 /var/www/owncloud/apps/user_ldap/lib/Proxy.php(138): OCA\User_LDAP\User_Proxy->callOnLastSeenOn('user777', 'checkPassword', Array, false)
#6 /var/www/owncloud/apps/user_ldap/lib/User_Proxy.php(194): OCA\User_LDAP\Proxy->handleRequest('user777', 'checkPassword', Array)
#7 /var/www/owncloud/lib/private/User/Manager.php(215): OCA\User_LDAP\User_Proxy->checkPassword('user777', 'password777')
#8 /var/www/owncloud/lib/private/User/Session.php(465): OC\User\Manager->checkPassword('user777', 'password777')
#9 /var/www/owncloud/lib/private/User/Session.php(299): OC\User\Session->loginWithPassword('user777', 'password777')
#10 /var/www/owncloud/core/Controller/LoginController.php(205): OC\User\Session->login('user777', 'password777')
#11 [internal function]: OC\Core\Controller\LoginController->tryLogin('user777', 'password777', NULL)
#12 /var/www/owncloud/lib/private/AppFramework/Http/Dispatcher.php(159): call_user_func_array(Array, Array)
#13 /var/www/owncloud/lib/private/AppFramework/Http/Dispatcher.php(89): OC\AppFramework\Http\Dispatcher->executeController(Object(OC\Core\Controller\LoginController), 'tryLogin')
#14 /var/www/owncloud/lib/private/AppFramework/App.php(98): OC\AppFramework\Http\Dispatcher->dispatch(Object(OC\Core\Controller\LoginController), 'tryLogin')
#15 /var/www/owncloud/lib/private/AppFramework/Routing/RouteActionHandler.php(46): OC\AppFramework\App::main('LoginController', 'tryLogin', Object(OC\AppFramework\DependencyInjection\DIContainer), Array)
#16 [internal function]: OC\AppFramework\Routing\RouteActionHandler->__invoke(Array)
#17 /var/www/owncloud/lib/private/Route/Router.php(299): call_user_func(Object(OC\AppFramework\Routing\RouteActionHandler), Array)
#18 /var/www/owncloud/lib/base.php(918): OC\Route\Router->match('/login')
#19 /var/www/owncloud/index.php(49): OC::handleRequest()
#20 {main}

#0 /var/www/owncloud/apps/user_ldap/lib/Connection.php(608): OCA\User_LDAP\LDAP->bind(Resource id #68, 'uid=user777,cn=...', 'password777')
#1 /var/www/owncloud/apps/user_ldap/lib/Access.php(1411): OCA\User_LDAP\Connection->bind()
#2 /var/www/owncloud/apps/user_ldap/lib/User_LDAP.php(134): OCA\User_LDAP\Access->areCredentialsValid('uid=user777,cn=...', 'password777')
#3 [internal function]: OCA\User_LDAP\User_LDAP->checkPassword('user777', 'password777')
#4 /var/www/owncloud/apps/user_ldap/lib/User_Proxy.php(106): call_user_func_array(Array, Array)
#5 /var/www/owncloud/apps/user_ldap/lib/Proxy.php(138): OCA\User_LDAP\User_Proxy->callOnLastSeenOn('user777', 'checkPassword', Array, false)
#6 /var/www/owncloud/apps/user_ldap/lib/User_Proxy.php(194): OCA\User_LDAP\Proxy->handleRequest('user777', 'checkPassword', Array)
#7 /var/www/owncloud/lib/private/User/Manager.php(215): OCA\User_LDAP\User_Proxy->checkPassword('user777', 'password777')
#8 /var/www/owncloud/lib/private/User/Session.php(632): OC\User\Manager->checkPassword('user777', 'password777')
#9 /var/www/owncloud/lib/private/User/Session.php(667): OC\User\Session->checkTokenCredentials(Object(OC\Authentication\Token\DefaultToken), 'b5pijede0v5d9jf...')
#10 /var/www/owncloud/lib/private/User/Session.php(233): OC\User\Session->validateToken('b5pijede0v5d9jf...')
#11 /var/www/owncloud/lib/private/legacy/app.php(131): OC\User\Session->validateSession()
#12 /var/www/owncloud/lib/base.php(888): OC_App::loadApps(Array)
#13 /var/www/owncloud/index.php(49): OC::handleRequest()
#14 {main}

So it seems like OCA\User_LDAP\User_Proxy->checkPassword('user777', 'password777') is called indirectly three times:

LoginController.php(186) and once in LoginController.php(205). To me, this seems to happen because login and checkPassword both result in a bind request in the case of the LDAP plugin?
once at the aforementioned place in Session.php(632) This seems like an initial check of the token to me?

PVince81 · 2017-06-30T09:15:00Z

@jvillafanez ^

jvillafanez · 2017-06-30T13:31:58Z

From my point of view, and based on @fredreichbier 's traces, it seems that core is the one over-authenticating. LDAP just forward the request to LDAP, and I think it's a request that LDAP shouldn't cache, so if core keeps checking for the password over and over is something core should handle, not LDAP.

fredreichbier · 2017-07-05T19:51:51Z

Thank you for looking into this @jvillafanez! I thought a bit about how to fix this:

To get rid of request 2: I agree that authentication requests shouldn't be cached over time. However, if I see correctly, the two calls of OC\User\Manager->checkPassword('user777', 'password777') occur in the handling of the same HTTP request: Would it be feasible for the LDAP plugin to detect that it has already sent a bind request during the handling of the current HTTP request? I guess this would also improve login performance.
To get rid of request 3: This happens because $dbToken->getLastCheck() returns null. If I understand correctly, this denotes the time at which the token credentials were last checked. Would it be sensible to initially set this to the login time? I tried this by adding $dbToken->setLastCheck($this->time->getTime()); to DefaultTokenProvider->generateToken and indeed, this removes the third bind request. However, I realize that this location might not be the best place to set this value.

The issue that request 3 is repeated every five minutes was fixed by #28252 :)

felixboehm · 2017-07-12T22:37:58Z

"get rid of request 2", yes, in 9.1 core password is

In 10.0 this was reworked and looks good for me. Anyone tested with 10.0?
If that works in 10.0, how hard is backport?

"get rid of request 3", I agree on suggested solution, to initially set token's lastCheckTime to the login time. Makes sense.
@PVince81

PVince81 · 2017-07-13T08:22:00Z

@felixboehm already fixed in #28252 by @cornelinux.

But looking at the code it seems to be missing a way to turn the check of completely: https://github.com/owncloud/core/pull/28269/files#diff-9c47cee6ac987e5256aeee509f91ddb1R611.

cornelinux · 2017-07-13T08:29:01Z

@PVince81 @felixboehm
For me it was ok, to not turn the check of completely.
I would simply set this to 8 hours or 24 hours. After all for me this is important for OTP authentication. And I am happy, if the user needs to enter a one time password once a day!

PaulHughes99 · 2017-07-13T11:12:00Z

@PVince81 <https://github.com/pvince81> @felixboehm <https://github.com/felixboehm> Likewise, calling my LDAP initiates 2FA, so (the option of) authenticating every 24 hours would be perfect ... otherwise users are driven crazy.

…

On 13/07/2017 09:29, Cornelius Kölbel wrote: @PVince81 <https://github.com/pvince81> @felixboehm <https://github.com/felixboehm> For me it was ok, to not turn the check of completely. I would simply set this to 8 hours or 24 hours. After all for me this is important for OTP authentication. And I am happy, if the user needs to enter a one time password once a day! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26065 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVBH28dRRY-IW8WEW-debAkg69Lt7fOsks5sNdVVgaJpZM4J33BC>.

fredreichbier · 2017-07-13T12:56:23Z

Thank you for looking into this @PVince81 @felixboehm! My backtraces above actually came from an installation of ownCloud 10.0.2, so the issue is still prevalent in ownCloud 10.

However, I just tried the current ownCloud master and user_ldap master. First, I had the problem that I couldn't log in at all using the user_ldap app due to a HTTP 500. This was caused by $loginResult in LoginController.php:204 being null. This is because $user is the name provided by the user (e.g. user333), but the oc_accounts table only seems to store UUIDs in the case of the user_ldap backend.
However, I replaced

$loginResult = $this->userManager->get($user);

with

$loginResult = $this->userSession->getUser();

which allows me to log in just fine. Do you think that change is sensible? I can also do a PR, if you prefer that.

And indeed, this eliminates request 2 from above. In conjunction with the setLastCheck fix from above, we are down to one LDAP bind request per login, which is great! :)

PVince81 · 2017-07-13T12:58:31Z

Cool, so do we agree to close this ticket ?

@fredreichbier if you are having other problems with LDAP latest versions, please raise a new ticket in https://github.com/owncloud/user_ldap

fredreichbier · 2017-07-13T13:17:18Z

Yes, I think if we can get the two one-line fixes merged into master, this ticket can be closed. Thanks!

Should I do two PRs? (since the first fix only removes the bind request 3, whereas the second fix seems necessary to get user_ldap running on the current master in general?)

PVince81 · 2017-07-13T13:27:42Z

@fredreichbier hmm I'm not really following what you mean. What PRs or fixes are you talking about ?

I'm only aware of the fix from #28252 which is already on master and stable10.

fredreichbier · 2017-07-13T13:57:18Z

Sorry if I didn't make this clear enough. The situation is the following:

On ownCloud 10.0.2, we still see three LDAP bind requests per login (see my backtraces here). The fix from #28252 only fixes the issue that the bind request 3 is repeated every five minutes.

On the master branch of ownCloud and user_ldap, the situation is the following:

We cannot login at all using the user_ldap backend because each login with correct credentials results in a HTTP 500. The one-line change I mention here seems to fix this. However, I have no idea if this is a user_ldap or a core issue :)
With this fix applied on master we can log in using the user_ldap backend again. Also, bind request 2 is gone (thanks to 9ffca34 I think), but ownCloud still sends two bind requests (i.e. requests 1 and 3 from above) per login. We can eliminate bind request 3 by setting the initial lastCheckTime of each token to the current time (by adding $dbToken->setLastCheck($this->time->getTime()); here).

So, all in all, applying these two fixes to master reduces the number of bind requests per login from 3 to 1. Please let me know if anything is unclear :)

PVince81 · 2017-07-13T13:59:23Z

@fredreichbier ok thanks. Please raise the issue about 500 in the user_ldap repo and/or submit your one-liner as PR. Whether this belongs to core and user_ldap, maybe @jvillafanez can help with that. But let's discuss this separate issue there.

PVince81 · 2017-07-19T13:29:26Z

Closing this now.

@fredreichbier when ready, please raise separate issue/PR and link them here. Thanks.

fredreichbier · 2017-07-22T17:11:40Z

Just a heads-up: I opened two issues (#28449 and #28467) and two pull requests (#28450 and #28468). With both PRs applied on master, it seems like one login request then corresponds to one Bind Request :)
Thank you for your help!

PVince81 · 2017-07-24T06:41:02Z

@fredreichbier thanks a lot!

lock · 2019-08-02T12:00:31Z

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

PaulHughes99 changed the title ~~LDAP over-authenticating after upgrade~~ LDAP over-authenticating after upgrade UPDATED/Simplified Sep 16, 2016

PVince81 added regression Type:Bug app:user_ldap labels Oct 6, 2016

PVince81 added this to the 9.1.2 milestone Oct 6, 2016

PVince81 modified the milestones: 9.1.3, 9.1.2 Oct 20, 2016

butonic added the green-ticket label Oct 20, 2016

PVince81 modified the milestones: 9.1.4, 9.1.3 Dec 22, 2016

PVince81 assigned jvillafanez Jan 19, 2017

PVince81 assigned IljaN and unassigned jvillafanez Jan 30, 2017

PVince81 reopened this Jun 30, 2017

felixboehm added the p1-urgent Critical issue, need to consider hotfix with just that issue label Jul 12, 2017

felixboehm modified the milestones: development, 9.1.7 Jul 12, 2017

felixboehm removed the green-ticket label Jul 12, 2017

felixboehm assigned PVince81 and unassigned jvillafanez Jul 12, 2017

PVince81 closed this as completed Jul 19, 2017

This was referenced Jul 20, 2017

Login via user_ldap app throws HTTP500 on current master #28449

Closed

Login via user_ldap sends two LDAP bind requests instead of one #28467

Closed

Initialize lastCheck when creating session token #28468

Merged

lock bot locked as resolved and limited conversation to collaborators Aug 2, 2019

LDAP over-authenticating after upgrade UPDATED/Simplified #26065

LDAP over-authenticating after upgrade UPDATED/Simplified #26065

Comments

PaulHughes99 commented Sep 8, 2016 • edited by cdamken Loading

Steps to reproduce

Expected behaviour

Server configuration

LDAP configuration (delete this part if not used)

PaulHughes99 commented Sep 14, 2016

PVince81 commented Oct 6, 2016

PVince81 commented Oct 6, 2016

PaulHughes99 commented Oct 6, 2016

PVince81 commented Oct 20, 2016

PVince81 commented Nov 9, 2016

jvillafanez commented Nov 17, 2016

felixboehm commented Dec 20, 2016

PVince81 commented Jan 11, 2017

PVince81 commented Jan 19, 2017

PVince81 commented Jan 19, 2017

PaulHughes99 commented Jan 19, 2017 via email

PaulHughes99 commented Jan 23, 2017

PVince81 commented Jan 23, 2017

PaulHughes99 commented Jan 23, 2017

PaulHughes99 commented Jan 24, 2017

PaulHughes99 commented Jan 27, 2017 • edited Loading

fredreichbier commented Jun 30, 2017

PVince81 commented Jun 30, 2017

jvillafanez commented Jun 30, 2017

fredreichbier commented Jul 5, 2017

felixboehm commented Jul 12, 2017

PVince81 commented Jul 13, 2017

cornelinux commented Jul 13, 2017

PaulHughes99 commented Jul 13, 2017 via email

fredreichbier commented Jul 13, 2017

PVince81 commented Jul 13, 2017

fredreichbier commented Jul 13, 2017

PVince81 commented Jul 13, 2017

fredreichbier commented Jul 13, 2017

PVince81 commented Jul 13, 2017

PVince81 commented Jul 19, 2017

fredreichbier commented Jul 22, 2017

PVince81 commented Jul 24, 2017

lock bot commented Aug 2, 2019

PaulHughes99 commented Sep 8, 2016 •

edited by cdamken

Loading

PaulHughes99 commented Jan 27, 2017 •

edited

Loading