6

I need to set up a local LDAP proxy cache which connects to our central Active Directory server. OpenLDAP Proxy Cache looks just like the thing. But following the manpages as closely as possible, I am not able to get it working.

I am able to proxy requests through localhost to the remote server, but they are not cached (or the cache not retrieved, at least).

The steps I made:

  • Installed openldap-servers and openldap-clients packages
  • Created a slapd.conf config file (details below)
  • Created a directory for the proxy database and copied the default DB_CONFIG file there (details below)
  • Ran slapd -d -1 command to start the server
  • Queried the server using this command: ldapwhoami -vvv -h localhost -D "CN=Melka Martin,OU=(...),DC=int,DC=ourdomain,DC=com" -x -w <password>

The result is success. But sniffing network trafic shows the query is pooled from the central LDAP server.

The slapd output is pretty verbose, but it does at one point state

QUERY NOT ANSWERABLE
QUERY CACHEABLE

Alas, if it does get cached, it is never answered. Any ideas what can be wrong?

"cn=admin,dc=int,dc=ourdomain,dc=com" is the DN of an admin user in the remote LDAP server. <something> is his password.

slapd.conf

database        ldap
suffix          "dc=int,dc=ourdomain,dc=com"
rootdn          "cn=admin,dc=int,dc=ourdomain,dc=com"
rootpw          <something>
uri             ldap://dc-04.int.ourdomain.com:389

overlay pcache
pcache         hdb 100000 1 1000 100
pcacheAttrset  0 *
pcacheTemplate (sn=) 0 3600
pcacheBind (sn=) 0 3600 sub dc=int,dc=ourdomain,dc=com

cachesize 200
directory /var/lib/ldap
index       objectClass eq
index       cn eq,sub

DB_CONFIG

# $OpenLDAP$

# one 0.25 GB cache
set_cachesize 0 268435456 1

# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152

The verbose log output: http://pastebin.com/9s8HMg7d

3
  • What version of OpenLDAP are you running? Would you be able to provide the verbose logs you're seeing when this occurs for a run or so? Post it with a link to reference that detail or else in a scrollable box in your answer? Nov 17, 2015 at 15:42
  • I am running v2.4.40. I updated the question with the output. Nov 19, 2015 at 10:50
  • I just added some detail as an answer in case it helps any. Let me know what you determine, etc. and I can add more detail if needed as well. These are just some more quick things I found that looked obvious with some reading and investigating the verbose logs you provided. Nov 20, 2015 at 4:45

2 Answers 2

0

Are you expecting to be cached the following query?

ldapwhoami -vvv -h localhost -D "CN=Melka Martin,OU=(...),DC=int,DC=ourdomain,DC=com" -x -w <password>

First of all I would change the templates to match the auth params:

pcacheTemplate (dn=) 0 3600
pcacheBind (dn=) 0 3600 sub dc=int,dc=ourdomain,dc=com

(dn is distinguished name, sn is surname)

But I would be surprised if it worked. In fact, I am not sure ldapwhoami is the right tool to test this overlay. The man page talks about authentication clients, for example nss_ldap. You should beforehand configure it and observe which queries it performs, so you can mimic template, scope and base.

2
  • Setting dn= for the template results in a "bad config file" thrown by slaptest, the slapd won't start ("attribute type undefined"). I want services running on the server to auth through the proxy cache, I thought ldapwhoami would be equivalent to what they call. I will look at nss_ldap. Nov 19, 2015 at 10:25
  • Maybe it's not even nss_ldap. I think you should focus to mimic your services' behaviour. If you have a recent box, sssd service is most likely then nss_ldap, but apache authnz_ldap bypasses it. Start by observing how your real service interacts with slapd.
    – 473183469
    Nov 19, 2015 at 10:35
0

A few things to mention which may be helpful or help narrow down a root cause. . .

FIRST

I wanted to point out that I noticed you were running slapd -d -1 which just means run slapd with debug and loggging level 1 meaning verbose/enable all debugging.

From what I read in the below post URL resource, if you do not run in the slapd -f <filename> syntax and fully qualify the <filename> to point to an "alternative" slapd.config file, then. . . "The default is normally /usr/local/etc/openldap/slapd.conf."

Therefore, this may not actually run slapd and point it to the configuration file to pick up the pointers/parameters you put in the alternative config file so give that a try first in case this is the issue.

May be related specifically to this error (ERROR PART1): 564da523 config_back_db_open: No explicit ACL for back-config configured. Using hardcoded default

(Resource: http://www.openldap.org/doc/admin24/runningslapd.html)


NOTE: I see a few DB related error messages in the verbose log you provided so perhaps it cannot find the applicable DB unless you change to that directory so it can find implicitly unless if supports some other explicit DB pointer method (NOTE2 may be aplicable to this method).

NOTE2: Here's a good read on the LDAP Proxy method and using the uri, etc. in the configuration this way just to review for something obvious you may be missing or misconfigured in the slapd.conf file (http://www.openldap.org/faq/data/cache/532.html).

A few Interesting Points from Note2 Section Resource

  • LDAP Proxy
  • binddn
  • bindpw
  • identity assertion
  • identity assertion configuration

VERSIONS

Firstly, it appears you are two versions back on OpenLADAP so it may be worth reading the release notes here to see if anything seems applicable to your problem (http://www.openldap.org/software/release/changes.html) which may justify upgrading or running from a test upgrade system if possible.

ERRORS

Secondly, the verbose log detail provides many more error messages, etc. and I wanted to point out ERROR PART 1, ERROR PART 2, ERROR PART 3, and ERROR PART 4 below specificially in that order.


Common causes of LDAP errors

(Resource: http://www.openldap.org/doc/admin24/appendix-common-errors.html)

From what I read up on, if you feel comfortable all your configurations are indeed setup correctly, the ERROR PART 1 first line may indeed just be a "warning" and safe to disgard.

However the line beneath that (~Using hardcoded default) may be the part per the FIRST section above as I listed the URL, etc.

ERROR PART 1

564da523 config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context
564da523 config_back_db_open: No explicit ACL for back-config configured. Using hardcoded default

Resources:


ERROR PART 2

564da523 <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988)
564da523 <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988)

In this one (above) I found an example here with slapd.conf files and one (below) stating this so I'm wondering if it's as simple as you needing to change to the DB directory in the slapd.conf file in your case.

(Resource: http://www.zytrax.com/books/ldap/ch5)

EXAMPLE FROM RESOURCE URL

# root or superuser
rootdn "cn=jimbob, dc=example, dc=com"
rootpw dirtysecret
# The database directory MUST exist prior to running slapd AND 
# change path as necessary
directory   /var/db/openldap/example-com

ERROR PART 3

Troubleshoot by using telnet <host> <port> to the LDAP IP address

May be useful as well (http://www.openldap.org/faq/data/cache/532.html)

ldap_read: want=8 error=Resource temporarily unavailable

ERROR PART 4

64da525 <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988)
564da525 => bdb_entry_get: cannot find entry: "cn=melka martin,ou=release engineering,ou=development,ou=research and development,ou=cz,dc=int,dc=company,dc=com"
564da525 QUERY NOT ANSWERABLE
564da525 QUERY CACHEABLE
1
  • @MartinMelka Check out my updated answer when you get a chance to see if it helps any. Start with the First section up top for how to pass a different argument/switch with the slapd command just in case it's as simple as that. Nov 20, 2015 at 4:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .