Why ldapsearch is not working with anonymous bind after upgrading OpenLDAP to v2.4

openldap

I have a setup of OpenLDAP v2.3 which I am using for last few years. Following are the lines in slapd.conf for access control.

access to dn.one="o=abc, c=IN"
        by * read

access to dn.base="o=abc, c=IN"
        by * none

When I do ldapsearch using anonymous bind gives me result.

For example following command gives result.

ldapsearch -x -h localhost -b "o=abc,c=IN"

Now I upgraded the OS, CentOS from 5.5 to 6.3 so the version of OpenLDAP is OpenLDAP v2.4. We have not changed the schema.

But now the same ldapsearch gives me result: 32 No such object error.

But it works when I added following line in access control configuration.

access to dn.one="o=abc, c=IN"
        by * read

access to dn.base="o=abc, c=IN"
        by anonymous read
        by * none

What can be the reason? Is there any security risk in doing so?

Best Answer

I posted the question on OpenLDAP mailing list and got the answer. Thanks to Pierangelo Masarati.

In OpenLDAP v2.4, search operation requires "search" privileges on the "entry" pseudo-attribute of the search base which was not the case in v2.3.

man slapd.access(5):

[...]

The search operation, requires search (=s) privileges on the entry pseudo-attribute of the searchBase (NOTE: this was introduced with OpenLDAP 2.4).

[...]

So I do not have to give read access to anonymous for base. Only search privilege is enough as following.

access to dn.base="o=abc, c=IN"
            by anonymous search
            by * none

I tested it successfully.

Related Solutions

Ldap – Using OpenLDAP to proxy to an Novell eDirectory LDAP Server

Since you are having issues with eDirectory, you are quite lucky, since you can use DSTrace with the LDAP option on to see what is going on, from the eDirectory server view.

Once you know what is being asked, and what the server is responding you can effectively troubleshoot the issue.

Basic eDirectory schema is complaint with LDAP and any standard LDAP schema should work for the most part. To get some specific features you might need some additional support, but that does not sound like your issue.

If you have access to the 10.10.1.27 box, try and look at it via http://10.10.1.27:8008 (or possibly port 8010, or 8028 depending if you are running eDirectory on Netware, Windows or a Unix variant respectively). This should redirect you to an https:// connection one port number higher (8009, 8010, or 8030 (ya 2 not 1)). Look for iMonitor or Dstrace, and then clear all the other flags, and enable the LDAP flag. Then the Dstrace Live icon will refresh on each click with the latest transactions.

Now as to your issue of:

there's almost no hierarchy. (I can set a base DN and view a particular object... but if I set the real base DN... I can only see it... and no children.)

I would suspect this issue is more about not doing the right kind of query. Sounds like you are doing Entry not Subtree queries. This will be very obvious in Dstrace, as you will see a query event that looks something like:

10:19:01 B68BEBA0 LDAP: (10.1.1.42:55133)(0x0002:0x63) Search request:
base: "ou=people,o=acme,dc=com"
scope:2 dereference:3 sizelimit:1 timelimit:0 attrsonly:0
filter: "(&(objectClass=inetorgperson)(acme7DigitName=gxc1234))"
no attributes
10:19:01 B68BEBA0 LDAP: (10.1.1.42:55133)(0x0002:0x63) Empty attribute list implies all user attributes
10:19:01 B68BEBA0 LDAP: (10.1.1.42:55133)(0x0002:0x63) Sending search result entry "cn=gxc1234,ou=UNK,ou=People,o=acme,dc=com" to connection 0xa07e6c0

There the scope: 2 tells you it is an entry search. You want to see it do a subtree (0) level search in order to get what you are looking for.

You can read more about how I used this sort of tooling to debug the nonsense that SAP's GRC web interface does for LDAP data retrieval.

Ldap – OpenLDAP cannot add new schema

Try

ldapadd -Q -Y EXTERNAL -H ldapi:/// -f filesystem.ldif

This will only work if you work as root (uid=0) or via sudo and on the LDAP server direct. It connects to the LDAP server based on the user id and bypasses the normal auth methods.

This access is granted by the olcAccess rule

{0}to *  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage  by * none

in olcDatabase={0}config,cn=config.

To allow access in the "normal" way, you can add the following lines to olcDatabase={0}config,cn=config:

olcRootDN: cn=admin,cn=config
olcRootPW: <yourpassword>

where <yourpassword> should be pre-encrypted via slappasswd.

Best Answer

Related Solutions

Ldap – Using OpenLDAP to proxy to an Novell eDirectory LDAP Server

Ldap – OpenLDAP cannot add new schema

Related Topic