BindFailedException with working credentials
Open
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 17
- Forks
- 19
- Avg merge
- 11h 40m
- Merged PRs (30d)
- 2
Description
Since a few weeks I've been unable to get owncloud to use our openLDAP, the used config has worked for over a year, but is now failing. Owncloud 10.15.2, user_ldap 0.19.1 is running in docker.
Config test via occ:
root@77dff291308d:/var/www/owncloud# occ -vvvv ldap:test-config ''
In Connection.php line 608:
[OCA\User_LDAP\Exceptions\BindFailedException]
Exception trace:
at /var/www/owncloud/apps/user_ldap/lib/Connection.php:608
OCA\User_LDAP\Connection->establishConnection() at /var/www/owncloud/apps/user_ldap/lib/Connection.php:212
OCA\User_LDAP\Connection->getConnectionResource() at /var/www/owncloud/apps/user_ldap/lib/Connection.php:701
OCA\User_LDAP\Connection->bind() at /var/www/owncloud/apps/user_ldap/lib/Command/TestConfig.php:114
OCA\User_LDAP\Command\TestConfig->testConfig() at /var/www/owncloud/apps/user_ldap/lib/Command/TestConfig.php:84
OCA\User_LDAP\Command\TestConfig->execute() at /var/www/owncloud/lib/composer/symfony/console/Command/Command.php:298
Symfony\Component\Console\Command\Command->run() at /var/www/owncloud/lib/composer/symfony/console/Application.php:1040
Symfony\Component\Console\Application->doRunCommand() at /var/www/owncloud/lib/composer/symfony/console/Application.php:301
Symfony\Component\Console\Application->doRun() at /var/www/owncloud/lib/composer/symfony/console/Application.php:171
Symfony\Component\Console\Application->run() at /var/www/owncloud/lib/private/Console/Application.php:165
OC\Console\Application->run() at /var/www/owncloud/console.php:94
require_once() at /var/www/owncloud/occ:11
ldap:test-config <configID>
Used config:
root@77dff291308d:/var/www/owncloud# occ ldap:show-config ''
+-------------------------------+----------------------------------------------+
| Configuration | |
+-------------------------------+----------------------------------------------+
| hasMemberOfFilterSupport | |
| hasPagedResultSupport | |
| homeFolderNamingRule | |
| lastJpegPhotoLookup | 0 |
| ldapAgentName | cn=admin,REDACTED |
| ldapAgentPassword | *** |
| ldapAttributesForGroupSearch | |
| ldapAttributesForUserSearch | uid |
| ldapBackupHost | |
| ldapBackupPort | |
| ldapBase | REDACTED |
| ldapBaseGroups | REDACTED |
| ldapBaseUsers | ou=people,REDACTED |
| ldapCacheTTL | 600 |
| ldapConfigurationActive | 1 |
| ldapDynamicGroupMemberURL | |
| ldapEmailAttribute | |
| ldapExperiencedAdmin | 0 |
| ldapExpertGroupnameAttr | cn |
| ldapExpertUUIDGroupAttr | |
| ldapExpertUUIDUserAttr | entryuuid |
| ldapExpertUsernameAttr | |
| ldapExposedAttributesForUser | |
| ldapGroupDisplayName | cn |
| ldapGroupFilter | (&(|(objectclass=groupOfNames))(|(cn=NONE))) |
| ldapGroupFilterGroups | REDACTED |
| ldapGroupFilterMode | 1 |
| ldapGroupFilterObjectclass | groupOfNames |
| ldapGroupMemberAlgo | groupScan |
| ldapGroupMemberAssocAttr | uniqueMember |
| ldapHost | ldaps://REDACTED |
| ldapIgnoreNamingRules | |
| ldapLoginFilter | (uid=%uid) |
| ldapLoginFilterAttributes | |
| ldapLoginFilterEmail | 0 |
| ldapLoginFilterMode | 1 |
| ldapLoginFilterUsername | 1 |
| ldapNestedGroups | 0 |
| ldapNetworkTimeout | 2 |
| ldapOverrideMainServer | |
| ldapPagingSize | 500 |
| ldapPort | 636 |
| ldapQuotaAttribute | |
| ldapQuotaDefault | |
| ldapTLS | 0 |
| ldapUserDisplayName | cn |
| ldapUserDisplayName2 | ou=people,REDACTED |
| ldapUserFilter | (|(objectclass=inetOrgPerson)) |
| ldapUserFilterGroups | |
| ldapUserFilterMode | 1 |
| ldapUserFilterObjectclass | inetOrgPerson |
| ldapUserName | samaccountname |
| ldapUuidGroupAttribute | auto |
| ldapUuidUserAttribute | auto |
| turnOffCertCheck | 0 |
| useMemberOfToDetectMembership | 1 |
+-------------------------------+----------------------------------------------+
Doing an ldap-search from the host machine does connect:
ldapsearch -H ldaps://REDACTED -D "cn=admin,REDACTED" -W -b "ou=people,REDACTED"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=people,REDACTED> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
REDACTED
# search result
search: 2
result: 0 Success
# numResponses: 5
# numEntries: 4
I don't think it's a connection or TLS issue, as I can see owncloud trying to connect in de logs of slapd:
May 26 09:41:16 REDACTED slapd[808]: conn=1033 fd=12 ACCEPT from IP=172.18.0.4:34712 (IP=0.0.0.0:636)
May 26 09:41:17 REDACTED slapd[808]: conn=1033 fd=12 TLS established tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM
May 26 09:41:17 REDACTED slapd[808]: conn=1033 fd=12 closed (connection lost)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with apps/user_ldap/lib/Connection.php around establishConnection() and bind(), then follow the ldap:test-config path in apps/user_ldap/lib/Command/TestConfig.php. Reproduce the command with the supplied configuration and compare its bind behavior with the successful host ldapsearch and slapd logs. Done means identifying why the bind closes after TLS establishment and adding a regression test for the failure.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, php
- Domain
- authentication, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100