[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Meta Directory err=32 'No Such Object' Returns the Object :-)

To: <wbormann@purdue.edu>
Subject: Re: Meta Directory err=32 'No Such Object' Returns the Object :-)
From: "Pierangelo Masarati" <ando@sys-net.it>
Date: Mon, 17 May 2004 22:13:55 +0200 (CEST)
Cc: <openldap-software@OpenLDAP.org>
Importance: Normal
In-reply-to: <1084823686.18446.1488.camel@gibson.itsp.purdue.edu>
References: <1084820495.18445.1467.camel@gibson.itsp.purdue.edu> <62018.81.72.89.40.1084822193.squirrel@webmail.sys-net.it> <1084823686.18446.1488.camel@gibson.itsp.purdue.edu>

So looks like at least one of the targets is returning a no such object,
which is erroneously used as return code because it is the worst error
that's occurring.  Of course, this means that there's a misconfiguration,
i.e. at least one of the targets is hit in a bad way, or the massaging
rules result in an invalid search base for that target or the target is
empty or so.  Can you check about this?  I.e., see if the logs can tell
you what search base is being used for each target, and try that search
yourself and see if a no such object is returned.  In any case, I'm not
sure this is a bug yet; I insist for misconfiguration, unless the no such
object is returned arbitrarily, without any of the targets being faulty.

p.

>
> Pierangelo,
>
> Thanks for your reply.
>
> Sorry, I meant to include the version number.  It is 2.2.11 running on a
> RedHat 8 box.
>
> Actually, the configuration file contains other entries, but I didn't
> include the entire file in the message as hits against other directories
> didn't seem important, but I should have known better :-)  For
> completeness here's the entire file:
>
> =================================================================
> # $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.8.8.7 2001/09/27
> 20:00:31 kurt Exp $
> #
> # See slapd.conf(5) for details on configuration options.
> # This file should NOT be world readable.
> #
> include         /home/wbormann/repository/schemas/core.schema
> include         /usr/local/etc/openldap/schema/cosine.schema
> include         /home/wbormann/repository/schemas/inetorgperson.schema
> include         /home/wbormann/repository/schemas/I2A2.schema
> include         /usr/local/etc/openldap/schema/openldap.schema
> include         /usr/local/etc/openldap/schema/misc.schema
> include
> /home/wbormann/EnterpriseDirectory/schemas/IBMContainer.schema
>
> #
> # Global Directives
> #
> #
> access to dn.base="" by * read
> access to dn.base="dc=purdue,dc=edu"
>         by * read
>
> #
> # TLS Authentication Client Parameters
> #
> loglevel        256
> sizelimit       50000
> TLSCACertificateFile    /home/wbormann/repository/certs/PurdueP.pem
> TLSCertificateFile      /home/wbormann/repository/certs/RepositoryP.pem
> TLSCertificateKeyFile   /home/wbormann/repository/certs/RepositoryV.pem
> TLSCipherSuite          MEDIUM:+TLSv1
> TLSCipherSuite          MEDIUM:+SSLv3
>
> # Do not enable referrals until AFTER you have a working directory #
> service AND an understanding of referrals.
> #referral       ldap://root.openldap.org
>
> pidfile         /usr/local/var/ed-slapd.pid
> argsfile        /usr/local/var/ed-slapd.args
>
> #######################################################################
> # Meta directory rules for cn=users,dc=purdue,dc=edu
> #######################################################################
>
> database meta
> lastmod off
> suffix "dc=purdue,dc=edu"
>
> #
> # Rewrite rules for user authentication against I2A2
> #
> uri
> "ldaps://dbm.i2a2.purdue.edu:636/cn=users,dc=purdue,dc=edu"
> suffixmassage   "cn=users,dc=purdue,dc=edu"
> "ou=authenticate,dc=purdue,dc=edu"
> map objectclass * *
> map attribute employeeNumber puid
>
> #
> # Rewrite rules for authorization against groups directory
> #
> uri
> "ldap://jaas.itsp.purdue.edu:2389/cn=groups,dc=purdue,dc=edu";
> suffixmassage   "cn=groups,dc=purdue,dc=edu"
> "cn=groups,dc=purdue,dc=edu"
>
> #
> # Rewrite rules for administrative DIT
> #
> uri
> "ldap://jaas.itsp.purdue.edu:2389/cn=administrators,dc=purdue,dc=edu";
> suffixmassage   "cn=administrators,dc=purdue,dc=edu"
> "cn=administrators,dc=purdue,dc=edu"
>
> #
> # Local Access Rules
> #
>
> access to dn.subtree="cn=users,dc=purdue,dc=edu"
>         by * read
>         by anonymous auth
>
> access to dn.subtree="cn=HRFLEX,cn=administrators,dc=purdue,dc=edu"
>         by dn="uid=wbormann,cn=users,dc=purdue,dc=edu" write
>         by
> dn="uid=wasadmin,cn=users,cn=HRFLEX,cn=administrators,dc=purdue,dc=edu"
> write
>         by
> dn="uid=wasbind,cn=users,cn=HRFLEX,cn=administrators,dc=purdue,dc=edu"
> read
>         by users read
>         by anonymous auth
>
> access to dn.subtree="cn=groups,dc=purdue,dc=edu"
>         by dn="uid=wbormann,cn=users,dc=purdue,dc=edu" write
>         by * read
>
> access to dn.subtree="cn=administrators,dc=purdue,dc=edu"
>         by dn="uid=wbormann,cn=users,dc=purdue,dc=edu" write
>         by users read
>         by anonymous auth
>
>
> Bill
>
>
> On Mon, 2004-05-17 at 14:29, Pierangelo Masarati wrote:
>
>> Hi.
>>
>> Usually this is the result of a misconfiguration.  I don't see any
>> significant error in your slapd.conf at a first glance; however, if
>> you could tell us the version of the software you're running this
>> could help a bit.  I note that if you need to point to just one
>> target, there's no need to use back-meta, you can use back-ldap, which
>> supports exactly the same mapping and rewirte features.
>>
>> p.
>>
>> >
>> > Greetings,
>> >
>> > I'm seeing something I think to be squirrelly and I'm not sure
>> exactly what's happening.
>> >
>> > I am running a search against a meta-directory, a la:
>> >
>> > ldapsearch -H "ldaps://jaas.itsp.purdue.edu:2490" -b
>> > "uid=wbormann,cn=users,dc=purdue,dc=edu" -s "base" -x -v
>> > "(objectClass=*)"
>> > ldap_initialize( ldaps://jaas.itsp.purdue.edu:2490 )
>> > filter: (objectClass=*)
>> > requesting: ALL
>> > # extended LDIF
>> > #
>> > # LDAPv3
>> > # base <uid=wbormann,cn=users,dc=purdue,dc=edu> with scope base #
>> filter: (objectClass=*)
>> > # requesting: ALL
>> > #
>> >
>> > # wbormann, users, purdue.edu
>> > dn: uid=wbormann,cn=users,dc=purdue,dc=edu
>> > objectClass: top
>> > objectClass: puidObject
>> > objectClass: uidObject
>> > cn: WILLIAM IRVIN BORMANN
>> > givenName: WILLIAM
>> > sn: BORMANN
>> > employeeNumber: 10099899
>> > uid: wbormann
>> >
>> > # search result
>> > search: 2
>> > result: 32 No such object
>> >
>> > # numResponses: 2
>> > # numEntries: 1
>> >
>> > ===================================================================
>> >
>> > The log for the search looks like:
>> >
>> > ===================================================================
>> >
>> > May 17 13:54:01 jaas slapd[20049]: slapd starting
>> > May 17 13:54:19 jaas slapd[20048]: conn=0 fd=10 ACCEPT from
>> > IP=128.210.177.118:40687 (IP=128.210.177.118:2490)
>> > May 17 13:54:19 jaas slapd[20054]: conn=0 op=0 BIND dn="" method=128
>> May 17 13:54:19 jaas slapd[20054]: conn=0 op=0 RESULT tag=97 err=0
>> text= May 17 13:54:19 jaas slapd[20054]: conn=0 op=1 SRCH
>> > base="uid=wbormann,cn=users,dc=purdue,dc=edu" scope=0 deref=0
>> > filter="(objectClass=*)"
>> > May 17 13:54:19 jaas slapd[20054]: conn=0 op=1 SEARCH RESULT tag=101
>> err=32 nentries=1 text=
>> > May 17 13:54:19 jaas slapd[20054]: conn=0 op=2 UNBIND
>> > May 17 13:54:19 jaas slapd[20054]: conn=0 fd=10 closed
>> >
>> > ===================================================================
>> >
>> > The configuration file for the cn=users,dc=purdue,dc=edu portion
>> looks like:
>> >
>> > ===================================================================
>> >
>> > #
>> > # Global Directives
>> > #
>> > #
>> > access to dn.base="" by * read
>> > access to dn.base="dc=purdue,dc=edu"
>> >         by * read
>> > #######################################################################
>> # Meta directory rules for cn=users,dc=purdue,dc=edu
>> > #######################################################################
>> >
>> > database meta
>> > lastmod off
>> > suffix "dc=purdue,dc=edu"
>> >
>> > #
>> > # Rewrite rules for user authentication against I2A2
>> > #
>> > uri
>> > "ldaps://dbm.i2a2.purdue.edu:636/cn=users,dc=purdue,dc=edu"
>> > suffixmassage   "cn=users,dc=purdue,dc=edu"
>> > "ou=authenticate,dc=purdue,dc=edu"
>> > map objectclass * *
>> > map attribute employeeNumber puid
>> >
>> > #
>> > # Local Access Rules
>> > #
>> >
>> > access to dn.subtree="cn=users,dc=purdue,dc=edu"
>> >         by * read
>> >         by anonymous auth
>> >
>> > ===================================================================
>> >
>> > What I don't understand is why an error is being reported but data
>> is being returned.  Isn't this incorrect?
>> >
>> > --
>> > William I. Bormann
>> > IT Security and Privacy
>> > Phone:  496-3186
>>


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it




    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

References:
- Meta Directory err=32 "No Such Object" Returns the Object :-)
  - From: "William I. Bormann" <wbormann@purdue.edu>
- Re: Meta Directory err=32 'No Such Object' Returns the Object :-)
  - From: "Pierangelo Masarati" <ando@sys-net.it>
- Re: Meta Directory err=32 'No Such Object' Returns the Object :-)
  - From: "William I. Bormann" <wbormann@purdue.edu>

Prev by Date: Re: ACL to block IPs
Next by Date: Re: ActiveDirectory Connector...
Index(es):
- Chronological
- Thread