Hi As there is no workaround, please file a bug report.
Kind regards, Christian Mack On 2012-03-06 10:20, Bruno Lingner (Hugo) wrote: > hi > > is there anyone with a solution here? should I file a bug for this? > I even tried to massage the ldap suffix, so that > ou=personen,ou=intern.. appears as > ou=personen,ou=sogo,ou=intern.. > and then set the base DN to > ou=sogo,ou=intern.. with subbranches users,groups,ressources and > locations, but it didn't take. searching with type SUB does not work > for some reason, only a direct search of the branch. > this is a bit of a pain, cos it would mean a hack in /etc/ldap.ini > for example, or some other way to circumvent it, avoiding moving ldap > branches around.. > > greets > hugo.- > > Am 02/14/2012 03:17 PM, schrieb Bruno Lingner (Hugo): >> hi list >> >> I see some strange behaviour with the groups in sogo. >> first search is using the configured filter in the .GNUstepDefaults. >> then it searches again, to try to decompose it to its list of members, >> but this time it doesn't use the configured filter :( >> I have to set the search path to a higher level >> (ou=intern,dc=example,dc=com), because the user accounts are here: >> ou=personen,ou=intern,dc=example,dc=com >> and the sogo groups/ressources/locations are defined here: >> ou=sogo,ou=intern,dc=example,dc=com >> but because we have other groups defined as e.g: >> ou=sendmail,ou=intern,dc=example,dc=com >> which is neither one of the objectClasses that sogo sees as groups. >> the last search for looking up group members, is something like: >> SRCH base="ou=intern,dc=example,dc=com" scope=2 deref=0 >> filter="([email protected])" >> and so it finds 2 results, one from ou=sendmail.. and one from ou=sogo.. >> therefore it doesn't decompose the groups properly. >> is it possible to change the code so it searches both times >> using the right filter I configured, or perhaps to search for >> the full DN of the group (result of the first search) the second time? >> >> LDAP debug info: >> ---> here I search for the group in the "Add Attendees" window: >> >> Feb 14 14:31:02 odalix slapd[7094]: conn=1018 fd=17 ACCEPT from >> IP=127.0.0.1:45720 (IP=0.0.0.0:389) >> Feb 14 14:31:02 odalix slapd[7094]: conn=1018 op=0 BIND dn="" method=128 >> Feb 14 14:31:02 odalix slapd[7094]: conn=1018 op=0 RESULT tag=97 err=0 >> text= >> Feb 14 14:31:02 odalix slapd[7094]: conn=1018 op=1 SRCH >> base="ou=intern,dc=example,dc=com" scope=2 deref=0 >> filter="(&(|(sn=support*)(cn=support*)(uid=support*)(mail=support*))(&(objectClass=KuPPerson)(KuPaktiv=aktiv)(mail=*)(!(ou:dn:=sendmail))))" >> >> >> Feb 14 14:31:02 odalix slapd[7094]: conn=1018 op=1 SRCH attr=objectClass >> cn uid mail title company o displayname modifytimestamp mozillahomestate >> mozillahomeurl homeurl st region mozillacustom2 custom2 >> mozillahomecountryname description notes department departmentnumber ou >> orgunit mobile cellphone carphone mozillacustom1 custom1 mozillanickname >> xmozillanickname mozillaworkurl workurl fax facsimiletelephonenumber >> telephonenumber mozillahomestreet mozillasecondemail xmozillasecondemail >> mozillacustom4 custom4 nsaimid nscpaimscreenname street streetaddress >> postofficebox homephone cn commonname givenname mozillahomepostalcode >> mozillahomelocalityname mozillaworkstreet2 mozillausehtmlmail >> xmozillausehtmlmail mozillahomestreet2 postalcode zip c countryname >> pager pagerphone mail sn surname mozillacustom3 custom3 l locality >> birthyear serialnumber calfburl proxyaddresses msExchHomeServerName kind >> multiplebookings >> Feb 14 14:31:02 odalix slapd[7094]: conn=1018 op=1 SEARCH RESULT tag=101 >> err=0 nentries=1 text= >> Feb 14 14:31:02 odalix slapd[7094]: conn=1018 op=2 UNBIND >> Feb 14 14:31:02 odalix slapd[7094]: conn=1018 fd=17 closed >> >> ---> here I save the appointment: >> >> Feb 14 14:31:12 odalix slapd[7094]: conn=1019 fd=17 ACCEPT from >> IP=127.0.0.1:45724 (IP=0.0.0.0:389) >> Feb 14 14:31:12 odalix slapd[7094]: conn=1019 op=0 BIND dn="" method=128 >> Feb 14 14:31:12 odalix slapd[7094]: conn=1019 op=0 RESULT tag=97 err=0 >> text= >> Feb 14 14:31:12 odalix slapd[7094]: conn=1019 op=1 SRCH >> base="ou=intern,dc=example,dc=com" scope=2 deref=0 >> filter="([email protected])" >> Feb 14 14:31:12 odalix slapd[7094]: conn=1019 op=1 SRCH attr=objectClass >> cn uid mail title company o displayname modifytimestamp mozillahomestate >> mozillahomeurl homeurl st region mozillacustom2 custom2 >> mozillahomecountryname description notes department departmentnumber ou >> orgunit mobile cellphone carphone mozillacustom1 custom1 mozillanickname >> xmozillanickname mozillaworkurl workurl fax facsimiletelephonenumber >> telephonenumber mozillahomestreet mozillasecondemail xmozillasecondemail >> mozillacustom4 custom4 nsaimid nscpaimscreenname street streetaddress >> postofficebox homephone cn commonname givenname mozillahomepostalcode >> mozillahomelocalityname mozillaworkstreet2 mozillausehtmlmail >> xmozillausehtmlmail mozillahomestreet2 postalcode zip c countryname >> pager pagerphone mail sn surname mozillacustom3 custom3 l locality >> birthyear serialnumber calfburl proxyaddresses msExchHomeServerName kind >> multiplebookings member uniqueMember memberUid memberOf >> Feb 14 14:31:12 odalix slapd[7094]: conn=1019 op=1 SEARCH RESULT tag=101 >> err=0 nentries=2 text= >> Feb 14 14:31:12 odalix slapd[7094]: conn=1019 op=2 UNBIND >> Feb 14 14:31:12 odalix slapd[7094]: conn=1019 fd=17 closed >> >> >> greetings >> hugo.- -- Christian Mack Gruppe Informationsdienste Rechenzentrum Universität Konstanz -- [email protected] https://inverse.ca/sogo/lists
