(ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by tgates81＠gmail.com
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
12 years, 6 months
Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu
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
12 years, 6 months
Re: (ITS#6944) Add option to limit or remove operation list cache
by quanah＠zimbra.com
--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
12 years, 6 months
(ITS#6947) ldapadd crashes with LDIFs with invalid line termination
by jvcelak＠redhat.com
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
12 years, 6 months
(ITS#6945) nssov does not build on older Linux distributions (RHEL3, RHEL4)
by bgmilne＠staff.telkomsa.net
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.
12 years, 6 months
Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it
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.
12 years, 6 months
(ITS#6944) Add option to limit or remove operation list cache
by jorge.perez.burgos＠ericsson.com
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.
12 years, 6 months
Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu
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
12 years, 6 months
Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it
> 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.
12 years, 6 months
