search

nextcloud / server

☁️ Nextcloud server, a safe home for all your data
https://nextcloud.com
GNU Affero General Public License v3.0
26.71k stars 4k forks source link

LDAP entries with DN > 255 characters are unsupported #2213

Closed KB7777 closed 2 years ago

KB7777 commented 7 years ago

Steps to reproduce

  1. Click at the Users page

Expected behaviour

Showing users at Users page

Actual behaviour

There is no users at Users page:

2016-11-17 13_25_35

Additional info: When I click at any group usrers are showing. When I disable LDAP plugin users are showing. But, sometimes it load only few records from LDAP.

The users from AD can log in with no problems. At least the few ones which I tested recently. I have over 1500 users at my OU.

Server configuration

Operating system: fully patched CentOS Linux release 7.2.1511 (Core)

Web server: Name : httpd Arch : x86_64 Version : 2.4.6 Release : 40.el7.centos.4

Database: Name : MariaDB-server Arch : x86_64 Version : 10.1.19 Release : 1.el7.centos

PHP version: Name : php55 Arch : x86_64 Version : 2.0 Release : 1.el7

Nextcloud version: (see Nextcloud admin page) 10.0.1 (stable)

Updated from an older Nextcloud/ownCloud or fresh install: Fresh install

Where did you install Nextcloud from: downloaded tar.gz from Nextcloud portal

List of activated apps: Enabled:

Disabled:

The content of config/config.php: { "system": { "instanceid": "ocmvtc6rlvl3", "passwordsalt": "REMOVED SENSITIVE VALUE", "secret": "REMOVED SENSITIVE VALUE", "trusteddomains": [ "REMOVED SENSITIVE VALUE", "REMOVED SENSITIVE VALUE" ], "datadirectory": "\/var\/www\/html\/nextcloud\/data", "overwrite.cli.url": "http:\/\/REMOVED SENSITIVE VALUE\/nextcloud", "dbtype": "mysql", "version": "9.1.1.5", "dbname": "nextcloud", "dbhost": "localhost", "dbport": "", "dbtableprefix": "oc", "dbuser": "REMOVED SENSITIVE VALUE", "dbpassword": "REMOVED SENSITIVE VALUE", "logtimezone": "UTC", "installed": true, "appstore.experimental.enabled": true, "loglevel": 0, "mail_smtpmode": "smtp", "mail_from_address": "nextcloud", "mail_domain": "REMOVED SENSITIVE VALUE", "mail_smtphost": "REMOVED SENSITIVE VALUE", "mail_smtpport": "25", "htaccess.RewriteBase": "\/nextcloud", "knowledgebaseenabled": false, "enable_avatars": false, "allow_user_to_change_display_name": false, "enable_previews": false, "ldapIgnoreNamingRules": false, "ldapProviderFactory": "\OCA\User_LDAP\LDAPProviderFactory" "memcache.local": "\OC\Memcache\APCu" } }

Are you using external storage, if yes which one: local/smb/sftp/... No.

Are you using encryption: yes/no No.

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/... Active Directory.

LDAP configuration (delete this part if not used)

LDAP: +-------------------------------+----------------------------------------------------------------------+ | Configuration | | +-------------------------------+----------------------------------------------------------------------+ | hasMemberOfFilterSupport | 1 | | hasPagedResultSupport | | | homeFolderNamingRule | | | lastJpegPhotoLookup | 0 | | ldapAgentName | cn=app_nextcloud,ou=services,ou=Accounts,dc=REMOVED SENSITIVE VALUE,dc=com,dc=pl | | ldapAgentPassword | | | ldapAttributesForGroupSearch | | | ldapAttributesForUserSearch | | | ldapBackupHost | | | ldapBackupPort | | | ldapBase | ou=REMOVED SENSITIVE VALUE,ou=Accounts,dc=REMOVED SENSITIVE VALUE,dc=com,dc=pl | | ldapBaseGroups | ou=REMOVED SENSITIVE VALUE,ou=Accounts,dc=REMOVED SENSITIVE VALUE,dc=com,dc=pl | | ldapBaseUsers | ou=REMOVED SENSITIVE VALUE,ou=Accounts,dc=REMOVED SENSITIVE VALUE***,dc=com,dc=pl | | ldapCacheTTL | 600 | | ldapConfigurationActive | 1 | | ldapDynamicGroupMemberURL | | | ldapEmailAttribute | mail | | ldapExperiencedAdmin | 0 | | ldapExpertUUIDGroupAttr | | | ldapExpertUUIDUserAttr | | | ldapExpertUsernameAttr | | | ldapGroupDisplayName | cn | | ldapGroupFilter | | | ldapGroupFilterGroups | | | ldapGroupFilterMode | 0 | | ldapGroupFilterObjectclass | | | ldapGroupMemberAssocAttr | uniqueMember | | ldapHost | REMOVED SENSITIVE VALUE | | ldapIgnoreNamingRules | | | ldapLoginFilter | (&(&(|(objectclass=person)))(samaccountname=%uid)) | | ldapLoginFilterAttributes | | | ldapLoginFilterEmail | 0 | | ldapLoginFilterMode | 0 | | ldapLoginFilterUsername | 1 | | ldapNestedGroups | 0 | | ldapOverrideMainServer | | | ldapPagingSize | 0 | | ldapPort | 389 | | ldapQuotaAttribute | | | ldapQuotaDefault | 5 GB | | ldapTLS | 0 | | ldapUserDisplayName | displayname | | ldapUserDisplayName2 | | | ldapUserFilter | (&(|(objectclass=person))) | | ldapUserFilterGroups | | | ldapUserFilterMode | 1 | | ldapUserFilterObjectclass | person | | ldapUuidGroupAttribute | auto | | ldapUuidUserAttribute | auto | | turnOffCertCheck | 1 | | useMemberOfToDetectMembership | 0 | +-------------------------------+----------------------------------------------------------------------+

Client configuration

Browser: Last Chrome, last Firefox, IE11

Operating system: Windows 7 x64.

Logs

Web server error log

[Mon Nov 21 13:20:13.149953 2016] [:error] [pid 15131] [client 10.151.40.57:17459] PHP Fatal error: Call to a member function composeAndStoreDisplayName() on a non-object in /var/www/html/nextcloud/apps/user_ldap/lib/Access.php on line 552

Nextcloud log (data/nextcloud.log)

{"reqId":"WDLme7NW3PMD4XfybYQpegAAAAQ","remoteAddr":"10.151.40.57","app":"PHP","message":"Call to a member function composeAndStoreDisplayName() on a non-object at \/var\/www\/html\/nextcloud\/apps\/user_ldap\/lib\/Access.php#552","level":3,"time":"2016-11-21T12:20:13+00:00","method":"GET","url":"\/nextcloud\/settings\/users\/users?offset=0&limit=50&gid=&pattern=","user":"admin"}

MorrisJobke commented 7 years ago

https://github.com/nextcloud/server/blob/813f0a0f40dd42b28cd35d91616f3f87ef400861/apps/user_ldap/lib/User/Manager.php#L220-L220 <- this could return null and cause the above error.

We should make this more resistant against such errors - @blizzz

KB7777 commented 7 years ago

Another info -- if OU contains less accounts the page is showing up with no problems. Sometimes, if OU contains more accounts the page is showing not all users. if OU contains many more accounts the problem is like I discribed at first post.

blizzz commented 7 years ago

@MorrisJobke indeed, and I agree it needs some checking. Nevertheless to understand the issue (and handle it more properly), I am interested why null is even returned there. It is supposed to come directly from LDAP.

@KB7777 perhaps it is related to one (or more) faulty records. Could you switch to debug level logging, retry and provide the resulting logs? Hoping to find more answers there.

KB7777 commented 7 years ago

@blizzz I switched to debug mode and with big OU (2k users) I had 4 errors like: Debug user_ldap The ldap user manager returned null for 0B46xxxx-xxxx-43B2-xxxx-4B659078xxx 2016-11-30T13:33:31+01:00 admin

I spotted what is that object (normal user) and which OU contains it. Later I set that OU only at Nextcloud settings and I had more accounts with errors like "returned null for" :(

Every account is fine, users are working normally. Very strange.

blizzz commented 7 years ago

@KB7777

The message occurs when a list of users from LDAP is received and some information is stored in Nextcloud (displayname, email, avatar, etc. if applicable). However this message indicates an issue with some of the records: a user object cannot be instantiated.

It's a good question why this happens, since we just got it from LDAP. Could you check the records for reported UUIDs on LDAP? Maybe something is unusual about them?

Could you also the check the oc_ldap_user_mappings table in the database? Are they entries for the reported failing UUIDs? How do they look like?

Can the users with the reported UUIDs log in?

Otherwise, nothing else interessting in the log?

KB7777 commented 7 years ago

I am still invastigating, but is it possible the problem is caused by too long OU path? And polish characters-set at OU names?

blizzz commented 7 years ago

I am still invastigating, but is it possible the problem is caused by too long OU path?

Sounds unlikely… but how much is "too long"?

And polish characters-set at OU names?

Once upon a time I tested it successfully with Persian, so Polish characters should be fine, too.

One issue that could arise is when creating a username out of an attribute that contains special characters and transliteration is not possible. This, however, would just make affected users be skipped.

KB7777 commented 7 years ago

Hello @blizzz

I checked this problem with fresh NC11 and php7.1 instance and.. there is no problem :)

So, it could be NC10.0.1 bug, but IMO that was a problem with my installation. Maybe after upgrading php54 -> php55. I had a problem with upgrading to 10.0.2 -- https://help.nextcloud.com/t/10-0-1-10-0-2-php-problem/6152.

No, listing users works fine. I have another problem with ldap listings, but I think I will write another issue post :)

Regards.

blizzz commented 7 years ago

Thanks for getting back and keeping us up to date. Sure, shoot the other issue!

KB7777 commented 7 years ago

Hello again @blizzz !

I just discovered what is the cause of wrong listing users from ldap, so I reopen the issue. APCU! :)

with 'memcache.local' => '\OC\Memcache\APCu', there is no users listed. Without it the users are shown.

Log from debug from NC11 (x at GUID are mine edit):

    OC\User\NoUserException: xxxxxxxx-06EB-4460-B7D9-xxxxxxxxxxxx is not a valid user anymore
/var/www/html/nextcloud/lib/private/User/User.php - line 261: OCA\User_LDAP\User_LDAP->getHome('xxxxxxxx-06EB-4...')
/var/www/html/nextcloud/settings/Controller/UsersController.php - line 205: OC\User\User->getHome()
/var/www/html/nextcloud/settings/Controller/UsersController.php - line 266: OC\Settings\Controller\UsersController->formatUserForIndex(Object(OC\User\User))
[internal function] OC\Settings\Controller\UsersController->index(0, 50, '', '', '')
/var/www/html/nextcloud/lib/private/AppFramework/Http/Dispatcher.php - line 160: call_user_func_array(Array, Array)
/var/www/html/nextcloud/lib/private/AppFramework/Http/Dispatcher.php - line 90: OC\AppFramework\Http\Dispatcher->executeController(Object(OC\Settings\Controller\UsersController), 'index')
/var/www/html/nextcloud/lib/private/AppFramework/App.php - line 114: OC\AppFramework\Http\Dispatcher->dispatch(Object(OC\Settings\Controller\UsersController), 'index')
/var/www/html/nextcloud/lib/private/AppFramework/Routing/RouteActionHandler.php - line 47: OC\AppFramework\App main('OC\\Settings\\Con...', 'index', Object(OC\AppFramework\DependencyInjection\DIContainer), Array)
[internal function] OC\AppFramework\Routing\RouteActionHandler->__invoke(Array)
/var/www/html/nextcloud/lib/private/Route/Router.php - line 299: call_user_func(Object(OC\AppFramework\Routing\RouteActionHandler), Array)
/var/www/html/nextcloud/lib/base.php - line 1010: OC\Route\Router->match('/settings/users...')
/var/www/html/nextcloud/index.php - line 40: OC handleRequest()
{main}

Regards.

blizzz commented 7 years ago

@KB7777 is your LDAP behaving funny, or being behind a strange load balancer or proxy or anything like this? never mind.

blizzz commented 7 years ago

@KB7777 do you get the same effect over command line?

./occ ldap:search ""

(as web user)

KB7777 commented 7 years ago

@blizzz

With APCU and without -- listed only 15 accounts. Alphabetically :)

blizzz commented 7 years ago

@KB7777 15 is the default, you can specify a different limit using --limit=42 or also set a different offset, for instance. ./occ ldap:search --help shows you all the options.

Can you verify that APCu is enabled for command line? Typically it isn't and needs a config switch on PHP side.

KB7777 commented 7 years ago

@blizzz

ldap:search works fine:

[root@nc11 nextcloud]# sudo -u apache ./occ ldap:search --limit=10000 ""  |wc -l
1952

But, some users are shown like FirstName LastName GUID but some like GUID only. Log shows No DN found for xxxxxx-3B1B-4647-B152-xxxxxxxxx.

Can you verify that APCu is enabled for command line?

How can I check this?

blizzz commented 7 years ago

Check for apc.enable_cli=1 in your PHP config. This depends on your distribution, on an arch based one you would put it to /etc/php/conf.d/apcu.ini.

KB7777 commented 7 years ago 
[root@nc11 ~]# grep apc.enable_cli /etc/php.d/40-apcu.ini
;apc.enable_cli=0

When I change it to apc.enable_cli=1 and restarted httpd effect is the same. Some users are shown only with GUID.

blizzz commented 7 years ago

@KB7777 can you verify that the GUID-only users have the displayname attribute set? You could find out the DN by looking into the oc_ldap_user_mapping table in the database.

KB7777 commented 7 years ago

@blizzz Yes, they have.

But -- the column ldap_dn has varchar(255) and some Distinguished Names of my users has more than 255 characters.

blizzz commented 7 years ago

@KB7777 and only those are affected?

KB7777 commented 7 years ago

@blizzz

Yes, I think so. I checked about 15 accounts which shows up with GUID instead of "FirstName LastName" as it should be and all has the same issue -- cutted Distinguished Name at column ldap_dn.

blizzz commented 7 years ago

This is bad. The DN is used as a key and due to MySQL/InnoDB limitations the field cannot contain larger values.

Allowing longer DNs would require changes in the logic at least, making the code more complicated. Options that come to my mind right now are:

For now I am cannot think of a safe workaround unfortunately.

blizzz commented 7 years ago

P.S.: Out of curiosity, what makes your DNs so long @KB7777 ?

KB7777 commented 7 years ago

@blizzz Hm.

We have 2 problems in this thread.

  1. Displaying the Users page with GUID instead of "FirstName LastName" -- as you wrote, problem couldn't be easy to solve. Ok. So I have question -- Is that issue affects only for displaying users at the Users page? If it is, it is minor problem for now, because if I search user by the first and last name it finds properly (but show only GUID data).

  2. Displaying the whole Users page with APCU enabled is not working. Is it the same bug or another one?

And, ehh... I has many long named OU's inside OU's inside OU's, inside OU's (etc.) to represent company organization structure. We have got many departments, divisions and teams here. It's really overwhelmed but is untouchable right now (and it seems that never will be, heh :().

EDIT: Probably You know that, but I leave it here :) https://technet.microsoft.com/en-us/library/active-directory-maximum-limits-scalability(v=ws.10).aspx

Name Length Limitations for LDAP Simple Bind Operations During binds to the directory, simple LDAP bind operations limit the distinguished name (also known as DN) of the user to 255 total characters. If you attempt a simple LDAP bind with more than 255 characters, you might experience authentication errors, such as the following:

Error <49>: ldap_simple_bind_s() failed: Invalid Credentials 
Server error: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 57, v1771 
Error 0x80090308 The token supplied to the function is invalid

You can avoid this issue by ensuring that the applications, scripts, and utilities that attempt to bind to your directory use secure LDAP binds. You can also avoid this issue by reducing the depth of the OU structure or the length of the OU names. For example, the following distinguished name is 261 characters:

CN=BobKelly,OU=CorporateVicePresidents,OU=CorporateOfficers,OU=ViewOfPugetSoundOffices,OU=TopFloor,OU=Building1557,OU=CorporateCampus,OU=Redmond,OU=Washington,OU=NorthWestern,OU=UnitedStatesOfAmerica,OU=NorthAmerica,DC=BusinessGroup,DC=humongousinsurance,DC=com

If the OU named CorporateVicePresidents is shortened to CVP, the distinguished name for the user account BobKelly is only 242 characters.

KB7777 commented 7 years ago

Hello @blizzz . Could you just tell me if i am wrong or not that not showing users page with APCU enabled is related with too long Distinguished Names from LDAP?

Regards.

KB7777 commented 7 years ago

The same situation is with Redis :((

OC\User\NoUserException: 08E75300-06EB-4460-xxxx-xxxxxxxxxxxxx is not a valid user anymore
[internal function] OCA\User_LDAP\User_LDAP->getHome('08E75300-06EB-4...')
/var/www/html/nextcloud/apps/user_ldap/lib/User_Proxy.php - line 69: call_user_func_array(Array, Array)
/var/www/html/nextcloud/apps/user_ldap/lib/Proxy.php - line 141: OCA\User_LDAP\User_Proxy->walkBackends('08E75300-06EB-4...', 'getHome', Array)
/var/www/html/nextcloud/apps/user_ldap/lib/User_Proxy.php - line 215: OCA\User_LDAP\Proxy->handleRequest('08E75300-06EB-4...', 'getHome', Array)
/var/www/html/nextcloud/lib/private/User/User.php - line 261: OCA\User_LDAP\User_Proxy->getHome('08E75300-06EB-4...')
/var/www/html/nextcloud/settings/Controller/UsersController.php - line 205: OC\User\User->getHome()
/var/www/html/nextcloud/settings/Controller/UsersController.php - line 266: OC\Settings\Controller\UsersController->formatUserForIndex(Object(OC\User\User))
[internal function] OC\Settings\Controller\UsersController->index(0, 50, '', '', '')
/var/www/html/nextcloud/lib/private/AppFramework/Http/Dispatcher.php - line 160: call_user_func_array(Array, Array)
/var/www/html/nextcloud/lib/private/AppFramework/Http/Dispatcher.php - line 90: OC\AppFramework\Http\Dispatcher->executeController(Object(OC\Settings\Controller\UsersController), 'index')
/var/www/html/nextcloud/lib/private/AppFramework/App.php - line 114: OC\AppFramework\Http\Dispatcher->dispatch(Object(OC\Settings\Controller\UsersController), 'index')
/var/www/html/nextcloud/lib/private/AppFramework/Routing/RouteActionHandler.php - line 47: OC\AppFramework\App main('OC\\Settings\\Con...', 'index', Object(OC\AppFramework\DependencyInjection\DIContainer), Array)
[internal function] OC\AppFramework\Routing\RouteActionHandler->__invoke(Array)
/var/www/html/nextcloud/lib/private/Route/Router.php - line 299: call_user_func(Object(OC\AppFramework\Routing\RouteActionHandler), Array)
/var/www/html/nextcloud/lib/base.php - line 1010: OC\Route\Router->match('/settings/users...')
/var/www/html/nextcloud/index.php - line 40: OC handleRequest()
{main}
blizzz commented 7 years ago

@KB7777 There is one issue that throws an exception that makes the results not render. However, this is independent of caching.

blizzz commented 7 years ago

@KB7777 https://github.com/nextcloud/server/pull/3264 should fix rendering the users page, but the users with the too long DN would not be enabled to access Nextcloud so far. This just catches the defects.

KB7777 commented 7 years ago

@blizzz

Well. I have checked the behavior of this one more time and... Well, whole my project implementetion is under quesion mark :( The structure of AD is untouchable right now (too many business internal application works with OU's). The thing is -- the users with too long DN cannot login. I tried to manipulate with settings of Base DN or Base User Tree and it gives nothing. But I'm 100% sure when I was testing it with NC10 I could login with testing account with long DN. I don't know why. I can't reproduce those settings now.

The situation is very hard :(

KB7777 commented 7 years ago

Is it posssible to make any quick workaorund of logon problem? Maybe changing varchar to text type? Maybe PostgreSQL installations are not affected with varchar lenght? Unfortunatly I'm not database admin :(

Regards.

blizzz commented 7 years ago

But I'm 100% sure when I was testing it with NC10 I could login with testing account with long DN. I don't know why. I can't reproduce those settings now.

@KB7777 You perhaps could log in, but things won't work properly, and you could never be sure of something really breaking.

Is it posssible to make any quick workaorund of logon problem?

Changing types in the database does not help, only changing the length. Which will totally break with MySQL.

It might work with Postgres, but you need to keep Nextcloud patched.

linuxmalaysia commented 7 years ago

Hi,

I'm also having the same issue as per reported by @KB7777 . My project deployment depend on LDAP configuration for the existing user in LDAP can be used with Nextcloud.

Any workaround can be a help to us for the deployment.

blizzz commented 7 years ago

@linuxmalaysia do you also have LDAP DNs longer than 255 characters?

tohn commented 7 years ago

We had the same problem, but neither disabling APCu worked nor have we LDAP DNs longer than 255 characters. We "fixed" this problem by including everyone in the AD to the nextcloud group, since we had a subgroup with only a subset of our users in it, but not in the parent nextcloud group.

So:

CN=nextcloud,OU=res,OU=Groups,DC=example,DC=org
member: user1; user2; user3; user4

CN=subgroup,OU=nextcloud,OU=res,OU=Groups,DC=example,DC=org
member: user1; user3; user5; user6; user7

After adding user5, user6 and user7 to nextcloud it worked.

TheMrApostel commented 7 years ago

I had a similiar issue. I changed the LDAP configuration so new users get their last name as username instead of the LDAP UID. After one user was disabled and enabled again after some time i wasn't be able list the groups where this user was present, too. Maybe check you LDAP remnants with sudo -u www-data php occ ldap:show-remnants and delete all listed user with sudo -u www-data php occ user:delete [user] from your command line within the nextcloud folder. That solved my issue.

guicunha commented 7 years ago

I'm experiencing the some problem when i run sudo -u www-data .././occ ldap:search "" --limit=2000 |wc -l all my users were listed and when i sudo -u www-data php .././occ ldap:show-remnants again all m users listed again

I'm experiencing problems to login through ldap

+-------------------------------+-----------------------------------------------------------------------+
| Configuration                 |                                                                       |
+-------------------------------+-----------------------------------------------------------------------+
| hasMemberOfFilterSupport      | 1                                                                     |
| hasPagedResultSupport         |                                                                       |
| homeFolderNamingRule          |                                                                       |
| lastJpegPhotoLookup           | 0                                                                     |
| ldapAgentName                 | cn="Admin",cn="users", |
| ldapAgentPassword             | ***                                                                   |
| ldapAttributesForGroupSearch  |                                                                       |
| ldapAttributesForUserSearch   |                                                                       |
| ldapBackupHost                |                                                                       |
| ldapBackupPort                |                                                                       |
| ldapBase                      | ou="sede"                    |
| ldapBaseGroups                | ou="sede"                    |
| ldapBaseUsers                 | ou="sede",                    |
| ldapCacheTTL                  | 600                                                                   |
| ldapConfigurationActive       | 1                                                                     |
| ldapDefaultPPolicyDN          |                                                                       |
| ldapDynamicGroupMemberURL     |                                                                       |
| ldapEmailAttribute            | mail                                                                  |
| ldapExperiencedAdmin          | 0                                                                     |
| ldapExpertUUIDGroupAttr       |                                                                       |
| ldapExpertUUIDUserAttr        |                                                                       |
| ldapExpertUsernameAttr        |                                                                       |
| ldapGidNumber                 | gidNumber                                                             |
| ldapGroupDisplayName          | cn                                                                    |
| ldapGroupFilter               | (&(|(objectclass=group)))                                             |
| ldapGroupFilterGroups         |                                                                       |
| ldapGroupFilterMode           | 0                                                                     |
| ldapGroupFilterObjectclass    | group                                                                 |
| ldapGroupMemberAssocAttr      | member                                                                |
| ldapHost                      | 192.168.31.46                                                         |
| ldapIgnoreNamingRules         |                                                                       |
| ldapLoginFilter               | (&(&(|(objectclass=person)(objectclass=user)))(samaccountname=%uid))  |
| ldapLoginFilterAttributes     |                                                                       |
| ldapLoginFilterEmail          | 0                                                                     |
| ldapLoginFilterMode           | 0                                                                     |
| ldapLoginFilterUsername       | 1                                                                     |
| ldapNestedGroups              | 1                                                                     |
| ldapOverrideMainServer        |                                                                       |
| ldapPagingSize                | 500                                                                   |
| ldapPort                      | 389                                                                   |
| ldapQuotaAttribute            |                                                                       |
| ldapQuotaDefault              |                                                                       |
| ldapTLS                       | 0                                                                     |
| ldapUserDisplayName           | displayname                                                           |
| ldapUserDisplayName2          |                                                                       |
| ldapUserFilter                | (&(|(objectclass=person)(objectclass=user)))                          |
| ldapUserFilterGroups          |                                                                       |
| ldapUserFilterMode            | 0                                                                     |
| ldapUserFilterObjectclass     | person;user                                                           |
| ldapUuidGroupAttribute        | auto                                                                  |
| ldapUuidUserAttribute         | auto                                                                  |
| turnOffCertCheck              | 0                                                                     |
| turnOnPasswordChange          | 1                                                                     |
| useMemberOfToDetectMembership | 1                                                                     |
+-------------------------------+-----------------------------------------------------------------------+
guicunha commented 7 years ago

{"reqId":"y0oBAYTkzvRVdwhNfQI0","level":0,"time":"2017-07-24T21:31:28+00:00","remoteAddr":"192.168.31.229","user":"--","app":"user_ldap","method":"POST","url":"\/index.php\/login?user=guilherme.cunha","message":"No DN found for on 192.168.31.46","userAgent":"Mozilla\/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko\/20100101 Firefox\/54.0","version":"12.0.0.29"}

plinss commented 7 years ago

Same problem, Nextcloud 12.0.2, nginx, php-fpm7.0 on Debian Stretch. Commented out 'memcache.local' from the config and it started working (prior to that everything appeared to work except it simply didn't list any users from LDAP). Interestingly once it started working, I was able to restore the 'memcache.local' setting and it appears to continue to work (so far, responds to users being added and removed on the LDAP side at least)).

The log has a number of these entries:

ldap_search(): Partial search results returned: Sizelimit exceeded at /var/www/nextcloud/apps/user_ldap/lib/LDAP.php#293
vahem2lu commented 6 years ago

Same problem here as @plinss described. Although not with this error message. Yet I had

"message":"LDAP Login: Could not get user object for DN cn=sten aus,**LDAP BASE DN HERE**. Maybe the LDAP entry has no set display name attribute?","userAgent":"Mozilla\/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/60.0.3112.113 Safari\/537.36","version":"12.0.2.0"}

blizzz commented 6 years ago

Same problem here as @plinss described. Although not with this error message.

Then it's not the same.

The user record is missing a set display name attribute, as the error message exclaims.

koa73 commented 6 years ago

I've made some additional patch for decision this problem for me

  1. Modify two tables add additional columns ALTER TABLE oc_ldap_user_mapping CHANGE COLUMN ldap_full ldap_full TEXT COLLATE utf8_general_ci NOT NULL; ALTER TABLE oc_ldap_group_mapping CHANGE COLUMN ldap_full ldap_full TEXT COLLATE utf8_bin;

  2. Insert into ldap_dn UUID v5 which I make like thid $this->v5('1546058f-5a25-4334-85ae-e68f2a44bbaf', $fdn) where first constant value, second dn received from LDAP As a result I have unic value which I can make on fly from full dn string And keep primary key which made from dn

  3. Insert into ldap-full raw dn receved from Ldap

  4. Modify /apps/user_ldap/lib/Mapping/AbstractMapping.php AbstractMapping.php.gz

blizzz commented 6 years ago

The issue here is pretty clear: missing support for LDAP entries having DN of more than 255 character size. I updated the title accordingly. For anything else, please open a new issue.

MorrisJobke commented 6 years ago

Most likely nothing for 14 -> moving to 15.

ysfduzgun commented 5 years ago

"cannot map because the dn exceeds 255 characters" i solved this error. i m not recommending. But it works. NextCloud ver = 15.0.2 Solution = 1- disable ldap app from nextcloud admin panel. 2- systemctl stop apache2/nginx 3- delete [oc_ldap_group_mapping, oc_ldap_group_members, oc_ldap_user_mapping] tables from mysql commandline on your nextcloud db. 4- nextcloud/apps/user_ldap/appinfo/database.xml change below line (511)

   <field>
    <name>ldap_dn</name>
    <type>text</type>
    <notnull>true</notnull>
    <length>511</length>
    <default></default>
   </field>

5- nextcloud/apps/user_ldap/appinfo/database.xml delete lines below

   <index>
    <name>ldap_dn_users</name>
    <unique>true</unique>
    <field>
     <name>ldap_dn</name>
    </field>
   </index>

6- nextcloud/apps/user_ldap/lib/Mapping/AbstractMapping.php change lines below

(line 231)  **if(mb_strlen($fdn) > 511) {**
(line 233)  **'Cannot map, because the DN exceeds 511 characters: {dn}',**

7- systemctl start apache2/nginx 8- active ldap aps on nextcloud admin panel

PS : The only thing we can not hack is destiny :) .

szaimen commented 3 years ago

@blizzz is this issue still valid?

blizzz commented 3 years ago

it is

Roberto8004 commented 3 years ago

Modify the file NextCloud\user_ldap\lib\Mapping\AbstractMapping.php public function map($fdn, $name, $uuid) { if (mb_strlen($fdn) > 255) { <------ modify to value correct and modify table oc_ldap_user_mapping field ldap_dn

Steve-Hubert commented 2 years ago

Modify the file NextCloud\user_ldap\lib\Mapping\AbstractMapping.php public function map($fdn, $name, $uuid) { if (mb_strlen($fdn) > 255) { <------ modify to value correct and modify table oc_ldap_user_mapping field ldap_dn

@Roberto8004

Thanks ! It's work with this modification. I've just edit the table oc_ldap_groups_mapping in the place of oc_ldap_user_mapping Do you think i need to edit the table oc_ldap_user_mapping too ? Can it be a problem if the field ldap_dn of user_mapping does not have the same value as the AbstractMapping.php value ?

Thanks.

parhomdim commented 2 years ago

If it is correctly fixed the problem of high DN length why its fix not included in code of nextcloud release? What are the consequences of such the fix?

koa73 commented 2 years ago

This bug didn't resolved during many years, it's time to graduate it as a best feature of the product.