openldap-bugs May 2011

openldap-bugs@openldap.org

33 participants
70 discussions

(ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by tgates81＠gmail.com 22 May '11

22 May '11

Full_Name: Tyler Gates Version: 2.4.25 OS: Ubuntu 10.04 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.184.61.44) I've been fighting with a strange issue related to a backend database using a pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming there was just something wrong with my cn=config I decided to start back fresh using slapd.conf instead. Once I got the config working just fine I used slaptest to convert the config to a new cn=config. Unfortunately when I tried using -F cn=config instead of my -f slapd.conf, slapd failed with the same old message: May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning, database 0 (hdb) has no suffix May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one: starting "(unknown)" May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix. May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one (type=hdb, suffix="(null)"): bi_db_open failed! (-1) May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated The backend database has never required me specify a suffix since it is already specified in the ldap overlay and when I try to add it in I get slapd trying to open the database twice which results in the second instance having access issues thus rendering all of the database inaccessible to queries. I'm assuming there has been a configuration change in cn=config for this particular layout but slaptest has not been updated. Below is a copy of the flat file I used that worked fine but failed once converted to cn=config using slaptest -f slapd.conf -F /etc/ldap/slapd.d/ root@directory-proxy:~# grep "^[^#]" /etc/ldap/slapd.conf.back_ldap_ppcache include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/sudo.schema include /etc/ldap/schema/autofs.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/qmail.schema include /etc/ldap/schema/puppet.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_ldap moduleload back_hdb moduleload pcache moduleload ppolicy TLSCertificateFile /etc/ldap/ssl/slapd.crt TLSCertificateKeyFile /etc/ldap/ssl/slapd.key TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt loglevel -1 allow bind_anon_dn database config rootdn cn=admin,cn=config rootpw secret access to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break database ldap suffix "dc=domain,dc=com" rootdn "cn=Manager,dc=domain,dc=com" rootpw secret uri "ldaps://directory1.domain.com ldaps://directory2.domain.com" overlay pcache proxycache hdb 100000 3 1000 100 proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description memberUid uniqueMember objectClass proxyAttrset 1 cn automountInformation proxyAttrset 2 cn mail proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 proxyTemplate (&(objectClass=)(uid=)) 0 1800 proxyTemplate (&(objectClass=)(cn=)) 0 1800 proxyTemplate (&(objectClass=)) 0 1800 proxyTemplate (objectClass=) 0 1800 proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900 proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900 proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800 proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800 proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600 proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600 proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600 proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200 directory /var/lib/ldap cachesize 1000 idletimeout 600 idlcachesize 3000 index objectClass eq index cn,mail,surname,givenname eq,subinitial index uidNumber,gidNumber,memberuid,member,uniqueMember eq index uid eq,subinitial index nisMapName,automountInformation eq index userPassword,homeDirectory,loginShell,gecos,description eq index pcacheQueryID eq

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 20 May '11

20 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, masarati(a)aero.po...: > The bug is caused by the fact that "mapping" is always on, and slapo-rwm > checks whether there is anything it can/need to do about special > attributes, and it (incorrectly) assumed attributes have an equality rule. > It has nothing to do with the fact that you defined no rules for search > or so. > > The quick fix would be to check whether sat_equality is NULL; the > (possibly) long fix would be to entirely skip mapping when not needed. My apologies for the delay in responding. I've uploaded a patch, TimMooney-110520.patch to incoming. It tests that sat_equality is not NULL before dereferencing. Is this essentially what you had in mind as a fix? Tim

1 0

Re: (ITS#6944) Add option to limit or remove operation list cache
by quanah＠zimbra.com 20 May '11

20 May '11

--On May 19, 2011 8:03:00 AM +0000 jorge.perez.burgos(a)ericsson.com wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.21 > OS: SLES 10 SP3 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.235.15.243) > > > Our slapd uses 256 threads Why do you have 256 thread set? Do you have a 64-core box? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6947) ldapadd crashes with LDIFs with invalid line termination
by jvcelak＠redhat.com 19 May '11

19 May '11

Full_Name: Jan Vcelak Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20110519-ldif-countlines.patch Submission from: (NULL) (209.132.186.34) Hello, adding entries to LDAP database from file using ldapadd tool causes memory corruption error, when the last line of the input file is not terminated by '\n' character. The entries are added correctly. All version since 2.4.23 are affected. $ cat >/tmp/input.ldif << EOF > dn: cn=A,dc=my-domain,dc=com > objectClass: inetOrgPerson > objectClass: organizationalPerson > objectClass: person > objectClass: top > cn: A > sn: A > uid: A > mail: A(a)example.com > EOF $ wc -c /tmp/input.ldif 166 /tmp/input.ldif $ truncate -s 165 /tmp/input.ldif $ hexdump -c /tmp/input.ldif 0000000 d n : c n = A , d c = m y - d 0000010 o m a i n , d c = c o m \n o b j 0000020 e c t C l a s s : i n e t O r 0000030 g P e r s o n \n o b j e c t C l 0000040 a s s : o r g a n i z a t i o 0000050 n a l P e r s o n \n o b j e c t 0000060 C l a s s : p e r s o n \n o b 0000070 j e c t C l a s s : t o p \n c 0000080 n : A \n s n : A \n u i d : 0000090 A \n m a i l : A @ e x a m p l 00000a0 e . c o m 00000a5 $ ldapadd -H ldap:// -D cn=Manager,dc=my-domain,dc=com -x -w password -f /tmp/input.ldif adding new entry "cn=A,dc=my-domain,dc=com" *** glibc detected *** ldapadd: free(): invalid pointer: 0x0000000001c435c8 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3626e76d63] ldapadd[0x404505] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3626e1ee5d] ldapadd[0x4037e9] ======= Memory map: ======== ... I am attaching proposed patch, which fixes this issue. Thank you Jan

1 0

(ITS#6946) ldapexop: ber_free_buf: Assertion failed
by jvcelak＠redhat.com 19 May '11

19 May '11

Full_Name: Jan Vcelak Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-110519-ldapexop-double-free.patch Submission from: (NULL) (209.132.186.34) Hello. A problem with crashing ldapexop was reported to our bugzilla. All versions since 2.4.24 are affected. It seems that the bug was introduced by following change in ldapexop.c. http://www.openldap.org/devel/cvsweb.cgi/clients/tools/ldapexop.c.diff?r1=1… Easy to reproduce. With clean configuration run: $ ldapexop -H ldap:// -x whoami anonymous ldapexop: ../../../libraries/liblber/io.c:186: ber_free_buf: Assertion `((ber)->ber_opts.lbo_valid==0x2)' failed. Aborted Complete steps to reproduce in Fedora are specified in the original bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=699683 I think it is cause by double freeing the result. I am attaching a proposed patch. Please, review my change. Thank you. Jan

1 0

(ITS#6945) nssov does not build on older Linux distributions (RHEL3, RHEL4)
by bgmilne＠staff.telkomsa.net 19 May '11

19 May '11

Full_Name: Buchan Milne Version: 2.4.25 OS: Red Hat Enterprise Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.124.16) I am aware that these are old, and almost (or already) EOL distributions, but nssov does not build on RHEL3 and RHEL4. On RHEL3, I get: + make -C contrib/slapd-modules/nssov libdir=/usr/lib moduledir=/usr/lib/openldap2.4 make: Entering directory `/home/bgmilne/rpm/BUILD.rh3/openldap-2.4.25/contrib/slapd-modules/nssov' ../../../libtool --mode=compile gcc -g -O2 -I../../../include -I../../../include -I../../../servers/slapd -Inss-pam-ldapd -c alias.c mkdir .libs gcc -g -O2 -I../../../include -I../../../include -I../../../servers/slapd -Inss-pam-ldapd -c alias.c -fPIC -DPIC -o .libs/alias.o In file included from ../../../include/ldap_pvt_thread.h:21, from ../../../servers/slapd/slap.h:57, from nssov.h:43, from alias.c:23: ../../../include/ldap_int_thread.h:69: syntax error before "ldap_int_thread_rdwr_t" ../../../include/ldap_int_thread.h:69: warning: data definition has no type or storage class In file included from ../../../servers/slapd/slap.h:57, from nssov.h:43, from alias.c:23: ../../../include/ldap_pvt_thread.h:36: syntax error before "ldap_pvt_thread_rdwr_t" ../../../include/ldap_pvt_thread.h:36: warning: data definition has no type or storage class ../../../include/ldap_pvt_thread.h:154: syntax error before '*' token ../../../include/ldap_pvt_thread.h:157: syntax error before '*' token ../../../include/ldap_pvt_thread.h:160: syntax error before '*' token ../../../include/ldap_pvt_thread.h:163: syntax error before '*' token ../../../include/ldap_pvt_thread.h:166: syntax error before '*' token ../../../include/ldap_pvt_thread.h:169: syntax error before '*' token ../../../include/ldap_pvt_thread.h:172: syntax error before '*' token ../../../include/ldap_pvt_thread.h:175: syntax error before '*' token ../../../include/ldap_pvt_thread.h:191: syntax error before '*' token ../../../include/ldap_pvt_thread.h:194: syntax error before '*' token ../../../include/ldap_pvt_thread.h:197: syntax error before '*' token make: *** [alias.lo] Error 1 make: Leaving directory `/home/bgmilne/rpm/BUILD.rh3/openldap-2.4.25/contrib/slapd-modules/nssov' ldap_int_thread.h:69 #if defined( HAVE_PTHREAD_RWLOCK_DESTROY ) #define LDAP_THREAD_HAVE_RDWR 1 typedef pthread_rwlock_t ldap_int_thread_rdwr_t; #endif ldap_int_thread.h includes pthread.h, which includes bits/pthreadtypes.h which defines pthread_rwlock_t ... I can't see why this use fails, where the rest of OpenLDAP builds just fine prior to this. smbk5pwd is also affected. I don't have time to investigate further now, but wanted to capture what info I have now.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 19 May '11

19 May '11

The bug is caused by the fact that "mapping" is always on, and slapo-rwm checks whether there is anything it can/need to do about special attributes, and it (incorrectly) assumed attributes have an equality rule. It has nothing to do with the fact that you defined no rules for search or so. The quick fix would be to check whether sat_equality is NULL; the (possibly) long fix would be to entirely skip mapping when not needed. p.

1 0

(ITS#6944) Add option to limit or remove operation list cache
by jorge.perez.burgos＠ericsson.com 19 May '11

19 May '11

Full_Name: Jorge Perez Burgos Version: 2.4.21 OS: SLES 10 SP3 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) Our slapd uses 256 threads with conn_max_pending_auth 5000. We have seen that with certain network traffic and conditions a huge increased in the amount of memory. After using valgrind and a little study, we have seen slapd cache operation structure in a list. These lists are per thread and could reach high values, in some cases we have seen 12500 operations cached, so 256*12500 could reach around 3GB. It's suggested adding an option to disable this cache or limit the growth of this one for future versions.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 18 May '11

18 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, masarati(a)aero.po...: >> We don't have any definition for apple-group-nestedgroup in any of the >> schemas that I have loaded. It's not something we support. We're also >> not doing any proxying. Note also that the search base it's using >> (cn=groups,dc=ndsu,dc=nodak,dc=edu) isn't valid. So, it's some Apple >> system on campus that someone has set up to query our LDAP tree, looking >> for things that the Mac OS X expects to find, but that we don't have or >> support. >> >> One thing that confuses me a little -- I set the rwm-rewriteContext to >> "bindDN", which I perhaps incorrectly believed meant that rewriting would >> only be done for authenticated binds (i.e. not anonymous binds), and >> this client did not authenticate. I was under the mistaken impression >> that >> rwm shouldn't even be called in cases like this. I don't (currently) need >> to >> rewrite searches or results from searches, only the bind credentials, for >> when we eventually enable support for ldap authentication. >> >> Does that answer your question? Would it be helpful to see either my >> original slapd.conf or the slapd-config that results from the conversion? > > Yes, either would be useful. Thanks, p. Here it is. Thanks, Tim #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ #@ #@ TVM: this file is no longer used. All slapd configuration is done via #@ the LDAP/LDIF-based slapd-config(5) backend, using commands like ldapadd, #@ ldapmodify, etc. #@ #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ # # # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # TVM: changed all paths from /etc/openldap/schema to # /etc/local/openldap/schema. # TVM: prior slapd.conf files based on earlier distributions of openldap # had fewer default schemas included (the config file we used with 2.3.24 # on RH4 loaded only core, cosine, inetorgperson, misc, and our custom # ndusEduPerson.schema). # For the install on RHEL5, I started with the stock slapd.conf from openldap # 2.4.21 and then removed the ones I didn't think we needed, e.g. corba, # duaconf, dyngroup, java, nis, ppolicy, and collective. # #include /etc/local/openldap/schema/corba.schema include /etc/local/openldap/schema/core.schema include /etc/local/openldap/schema/cosine.schema #include /etc/local/openldap/schema/duaconf.schema #include /etc/local/openldap/schema/dyngroup.schema include /etc/local/openldap/schema/inetorgperson.schema #include /etc/local/openldap/schema/java.schema include /etc/local/openldap/schema/misc.schema #include /etc/local/openldap/schema/nis.schema include /etc/local/openldap/schema/openldap.schema #include /etc/local/openldap/schema/ppolicy.schema #include /etc/local/openldap/schema/collective.schema # # TVM: custom NDUS schema # include /etc/local/openldap/schema/ndusEduPerson.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # # TVM: the sizelimit and timelimits we've historically used for slapd # sizelimit 150 timelimit 180 # Load dynamic backend modules: # modulepath /usr/lib/openldap # or /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # # TVM: uncommented this, we need it for bindDN massaging # moduleload rwm.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/pki/tls/certs/ldap.NoDak.edu.crt TLSCertificateKeyFile /etc/pki/tls/certs/ldap.NoDak.edu.key # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # # TVM: FIXME: for testing just require encryption for simple_bind # TVM: this can't be enabled until Dale's code to populate LDAP is ready # for it. #security simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # # TVM: added NDUS access controls (Note: these were at the bottom of # the older slapd.conf file before, now they're in an earlier section). # # I think we should seriously revisit these # access to filter=(cn=anonymous) attrs=cn,sn by * none # # TVM: inserted this ACL between the two that have been present since # the beginning. This is to try prevent userPassword: from showing up # in ldapsearch output, but still allow it to be used for auth # access to attrs=userPassword by anonymous auth access to * by * read # # TVM: new with our OpenLDAP 2.4.x install: load the rwm overlay # and add rules so that binds with the iid work. # overlay rwm rwm-rewriteEngine on # define a rewriteMap function that returns the dn for a particular attr # This is straight out of the first bindDN example in slapo-rwm(5) rwm-rewriteMap ldap attr2dn "ldap://localhost/dc=nodak,dc=edu?dn?sub" rwm-rewriteContext bindDN # and now the magic: parse out the IID and pass it to the attr2dn function. # This is also almost exactly taken from slapo-rwm(5), though I'm using iid # instead of mail and I'm not anchoring the regex and using $1, so it doesn't # matter if it's qualified or not. rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database hdb suffix "dc=nodak,dc=edu" checkpoint 1024 15 # # TVM: I added these settings as part of the migration to 2.4.x. # These are pure guesses. If memory is still available, we should # probably increase both. Note section 21.4.3 of the guide, that indicates # the idlcachesize should match cachesize when using bdb, but it should # be 3*cachesize for hdb, which doesn't really make a lot # of sense to me, but oh well... See slapd-bdb for more info # cachesize 2048 idlcachesize 6144 # # TVM: using System V shared memory is much faster for recent versions of # the Linux kernel than using mmap(2) files, so we'll give it a try. # # shm_key can be anything, it just identifies a shared memory segment that # BDB can use for its shared memory regions. # shm_key 41 rootdn "cn=Someone Hidden, dc=ndsu, dc=nodak, dc=edu" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg rootpw {SHA}ceHixPjpYAryAobGXZyzztpweto= # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/data-1 # # Indices to maintain for this database # # TVM: with openldap 2.3.24 on RHEL4 we just commented all of these out and # added our own, some of which exactly duplicated these. I'll keep the first # two index lines and comment out the next three, then supplment with ours. # # Also, previously we maintained a presence (pres) index on *every* one of # these. Section 21.2.3 of the OpenLDAP admin guide makes it very clear # that presence indexing is almost always a bad idea. With that in mind, # I've removed presence indexing from all of these. # index objectClass eq index ou,cn,mail,surname,givenname eq,sub #index uidNumber,gidNumber,loginShell eq #index uid,memberUid eq,sub #index nisMapName,nisMapEntry eq,sub # # TVM: added indexes on all of these. # index mailLocalAddress,mailRoutingAddress,nid eq index iid,uid,services eq,sub index class,college,major eq,sub index group,department,institution,title eq,sub index physicalDeliveryOfficeName,telephoneNumber eq,sub # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM # # TVM: this is new with 2.4.x, we'll leave it enabled, see chapter 20 of # the admin guide. # # enable monitoring database monitor rootdn "cn=Someone Hidden, dc=ndsu, dc=nodak, dc=edu" # allow only rootdn to read the monitor access to * by * none

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 18 May '11

18 May '11

> In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, Pierangelo...: > >>> At the time of the search, the very last thing that was logged was >>> >>> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH >>> base="cn=groups,dc=ndsu,dc=nodak,dc=edu" scope=2 deref=0 >>> filter="(&(?objectClass=posixGroup)(?objectClass=apple-group)(objectClass=extensibleObject)(|(?apple-group-nestedgroup=ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B)))" >>> >>> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH attr=cn >>> apple-generateduid gidNumber apple-group-realname ttl sambaSID rid >>> primaryGroupID apple-keyword apple-group-nestedgroup >>> >>> >>> I'll happily provide any details that I've mistakenly left out or that >>> would >>> aid >>> in debugging the issue. >>> >>> The issue certainly could be caused by an error in my rwmRewriteRule, >>> but I >>> imagine that slapd shouldn't segfault even if my rwmRewriteRule is >>> wrong. >> >> Yes (I believe), and yes. I believe the mapping is being applied to an >> attribute that is not explicitly defined in the schema, but rather >> proxied or >> somehow treated as undefined. For this reason, the matching rule >> pointer is >> NULL. Can you check the definition of "apple-group-nestedgroup", if >> any? Of >> course, slapo-rwm should not crash on something like this. > > Thank you Pierangelo. > > We don't have any definition for apple-group-nestedgroup in any of the > schemas that I have loaded. It's not something we support. We're also > not doing any proxying. Note also that the search base it's using > (cn=groups,dc=ndsu,dc=nodak,dc=edu) isn't valid. So, it's some Apple > system on campus that someone has set up to query our LDAP tree, looking > for things that the Mac OS X expects to find, but that we don't have or > support. > > One thing that confuses me a little -- I set the rwm-rewriteContext to > "bindDN", which I perhaps incorrectly believed meant that rewriting would > only be done for authenticated binds (i.e. not anonymous binds), and > this client did not authenticate. I was under the mistaken impression > that > rwm shouldn't even be called in cases like this. I don't (currently) need > to > rewrite searches or results from searches, only the bind credentials, for > when we eventually enable support for ldap authentication. > > Does that answer your question? Would it be helpful to see either my > original slapd.conf or the slapd-config that results from the conversion? Yes, either would be useful. Thanks, p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2011