2

I am having some issues with OpenLDAP and Spring security, where the latter does a search with the whole path in dn (filter), and an empty base. OpenLDAP does not like this, and the query fails. The problem is that I have no control over the query, so I am thus wondering if it is possible to configure OpenLDAP to allow such queries.

Some details on how this works:

Spring first does a search for a user, with something like this:

base:ou=something,ou=something,dc=oh,dc=my,dc=god
filter:cn=someUsername

Then, it gets back a result, where the whole dn is put in, and base is an empty String, like this:

base:
filter:cn=someUsername,ou=something,ou=something,dc=oh,dc=my,dc=god

Then, it uses this result for a new search against the LDAP, which then fails.

Tobb
  • 523
  • 1
  • 5
  • 9
  • "the whole path in dn (filter)"? Out of curiosity, what filter does it use? AFAIK there is no standard filter format for searching by DN... – u1686_grawity Jul 08 '15 at 07:57
  • I'll add some details to my question.. – Tobb Jul 08 '15 at 08:03
  • So it doesn't even _use_ an actual filter. It sends the DN as a filter and expects it to match something, which it _never will_, because it's really searching for a `cn` that has the value `someUsername,ou=something,ou=something,dc=oh,dc=my,dc=god`. – u1686_grawity Jul 08 '15 at 08:11

1 Answers1

2

OpenLDAP needs to know the base DN so that it could choose which database to read from. I couldn't find any support for "global" searching across all databases.

However, you can add a new database with an empty base DN. With the relay backend it can forward all queries to your main database. See slapd-relay(5) for more elaborate examples (including even rewriting), but the general usage is:

database  relay
suffix    ""
relay     "dc=example,dc=org"

dn: olcDatabase=relay,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcSuffix:
olcRelay: dc=example,dc=org

(Also, I wonder if Spring really uses the empty base for all searches? Some programs obtain the Root DSE this way (located at base "", scope 'base'), in order to auto-discover the real base DNs and/or server capabilities.)

After the update, it seems that the real problem is Spring using a bad filter. It does not make sense to just send a DN as a filter, because you will actually end up searching for a cn that contains someUsername,ou=something,dc=something.

Instead, Spring should have used the DN as base:

base: cn=someUsername,ou=something,ou=something,dc=oh,dc=my,dc=god
scope: base
filter: (objectClass=*)

If it ever becomes necessary to filter by DN, I think a working way would be (entryDN=dn), e.g. (entryDN=cn=foo,ou=bar,ou=baz), though it varies between servers (entryDN is OpenLDAP-specific, while AD has distinguishedName, and so on).

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • See my edit for some more details. This probably won't work, since the whole DN-path is included in the search, so having something other than an empty base would lead to it not finding anything. – Tobb Jul 08 '15 at 08:06
  • @Tobb: That's the whole point of 'relay', to give you (and Spring) an empty base to search. The base is not the largest problem. Spring using **malformed filters** is the problem. – u1686_grawity Jul 08 '15 at 08:08
  • Indeed it is, but that is beyond my control AFAIK. But I'll add a question regarding Springs behaviour in stackoverflow as well.. – Tobb Jul 08 '15 at 08:10
  • @Tobb: I'm guessing it could be a bug in Spring, since similar searches are common in other programs – except with base & filter reversed. – u1686_grawity Jul 08 '15 at 08:15
  • Yeah, probably is, but strange thing is that I've tried multiple versions and still the same result.. I'm gonna try to see if Spring behaves the same in an environment where I know this works, if it does then the ldap there is more lenient.. otherwise, hopefully I just have some error in my config.. – Tobb Jul 08 '15 at 08:20