Hi Mike,
Am 17.09.19 um 17:38 schrieb Mike Gabriel: > What I did: > > 1. Setup a fresh 389-ds instance using jessie's original version > (see http://snapshot.debian.org/package/389-ds-base/1.3.3.5-4/) > > 2. Upgrade to +deb8u4, test login, LDAP queries, etc. > > -> worked > > 3. Upgrade to +deb8u5, test login, LDAP queries, etc. > > -> worked > > 4. Upgrade to +deb8u6, test login, LDAP queries, etc. > > -> worked > > Can you be any chance provide more info about this issue? What exactly > are the LDAP queries, that Nextcloud does on your 389-ds server? unfortunately not. It was an setup we don't have any more, we updated nextcloud and moved to an newer ldap version. And in fact at that time I couldn't figure out the exact problem since the queries worked when I provided them via ldapsearch command line. My notes about the error where: nextcloud-log: root@nextcloud:/etc# tail -f /srv/ncdata/nextcloud-demo/nextcloud.log {"reqId":"U7vRHqej7uRmeA2JsBIf","level":3,"time":"2018-10-26T16:26:40+00:00","remoteAddr":"88.198.xx.xxx","user":"--","app":"PHP","method":"POST","url":"\/login?redirect_url=\/apps\/files\/%3Fdir%3D\/%26fileid%3D955&user=demo%40example.org","message":"ldap_control_paged_result_response(): Result is: Protocol error (2) at \/opt\/nextcloud-demo\/apps\/user_ldap\/lib\/LDAP.php#74","userAgent":"Mozilla\/5.0 (X11; Linux x86_64; rv:52.0) Gecko\/20100101 Firefox\/52.0","version":"14.0.3.0"} Note the: "Protocol error (2)" When we encountered the bug we had an replication of multiple ldap servers with slightly different versions: Access log of the ldap server with 389-ds version 1.3.3.5-4+deb8u3: [26/Oct/2018:16:32:41.929490646 +0000] conn=5364586 op=0 BIND dn="uid=owncloud-bind,ou=Special Users,dc=example,dc=org" method=128 version=3 [26/Oct/2018:16:32:41.929803839 +0000] conn=5364586 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=owncloud-bind,ou=special users,dc=example,dc=org" [26/Oct/2018:16:32:41.987048655 +0000] conn=5364586 op=1 SRCH base="dc=example,dc=org" scope=2 filter="(&(|(objectClass=inetorgperson))(|(mail=d...@example.org)))" attrs="entryuuid nsUniqueId objectguid guid ipauniqueid distinguishedName uid samaccountname memberOf mail displayName jpegPhoto thumbnailphoto" [26/Oct/2018:16:32:41.987905862 +0000] conn=5364586 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=P pr_idx=0 pr_cookie=-1 [26/Oct/2018:16:32:42.459561451 +0000] conn=5364586 op=2 UNBIND [26/Oct/2018:16:32:42.459584128 +0000] conn=5364586 op=2 fd=825 closed - U1 Access log at the other one with 389-ds version 1.3.5.17-2: [26/Oct/2018:18:29:19 +0200] conn=66 op=0 BIND dn="uid=owncloud-bind,ou=Special Users,dc=example,dc=org" method=128 version=3 [26/Oct/2018:18:29:19 +0200] conn=66 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=owncloud-bind,ou=special users,dc=example,dc=org" [26/Oct/2018:18:29:19 +0200] conn=66 op=1 SRCH base="(null)" scope=2 filter="(&(|(objectClass=inetorgperson))(|(mail=d...@example.org)))", invalid attribute request [26/Oct/2018:18:29:19 +0200] conn=66 op=1 RESULT err=2 tag=101 nentries=0 etime=0 [26/Oct/2018:18:29:19 +0200] conn=66 op=2 SRCH base="(null)" scope=2 filter="(&(|(objectClass=inetorgperson))(|(mail=1d0b3c01-fd3f11e4-a213ad4c-cdc1d3d2)))", invalid attribute request [26/Oct/2018:18:29:19 +0200] conn=66 op=2 RESULT err=2 tag=101 nentries=0 etime=0 [26/Oct/2018:18:29:19 +0200] conn=66 op=3 SRCH base="(null)" scope=2 filter="(&(|(objectClass=inetorgperson))(|(mail=1d0b3c01-fd3f11e4-a213ad4c-cdc1d3d2)))", invalid attribute request [26/Oct/2018:18:29:19 +0200] conn=66 op=3 RESULT err=2 tag=101 nentries=0 etime=0 [26/Oct/2018:18:29:32 +0200] conn=66 op=4 UNBIND [26/Oct/2018:18:29:32 +0200] conn=66 op=4 fd=279 closed - U1 there ist an search base with "null" in access log. But this seems to happen on the server side. Providing the same query on command line worked. > Can anyone else give feedback about 389-ds in jessie LTS? Any observed > problems that look similar to #912224 [1]? Maybe we've been the only who where affected. Kind regards Jan