|
Update:
I reordered directives in slapd.conf and now slaptest recognizes the file, but with an error I haven't been able to resolve:
Given:
overlay chain
chain-uri ldap://chained-server.domain.com
chain-idassert-bind bindmethod="simple"
binddn="cn=admin,dc=domain,dc=com"
credentials="<password>"
mode="self"
chain-tls start
chain-return-error TRUE
sudo slaptest -f /etc/openldap/slapd.conf
56279f1f invalid bind config value binddn=cn=admin,dc=domain,dc=com
56279f1f /etc/openldap/slapd.conf: line 33: "idassert-bind <args>": unable to parse field "binddn=cn=admin,dc=domain,dc=com".
slaptest: bad configuration file!
Any assistance would be appreciated.
From: Peter Heinemann
Sent: Tuesday, October 13, 2015 11:43 AM To: openldap-technical@openldap.org Subject: openldap chain overlay: does not seem to be functioning/referenced openldap 2.4-39
RHEL 6.5
I'm trying to get one ldap server configured to chain queries to a second server when specific OUs that are on the 2nd server (but not the 1st) are referenced in a query/ldapsearch. Note that these are read-only consumers, so I am not dealing with modifications,
only searches. Both servers share the top level suffix.
An ldapsearch against the first server involving an OU that is on the second server returns "no such Object"; and the logfile on the first server (loglevel 1) shows no reference to the chain-uri or attempt to search outside the first server.
overlay chain
chain-uri ldap://chained-server.domain.com
chain-idassert-bind bindmethod="simple"
binddn="cn=admin,dc=domain,dc=com"
credentials="<password>"
mode="self"
chain-tls start
chain-return-error TRUE
slapd.conf is valid per slaptest, and starts successfully.
However, an ldapsearch against the initial target server simply returns "No such object", because it appears the chain is never followed or these directives are inactive. In the local4.log with loglevel set to 1, there's never any attempt/reference to
the chain-uri, and no subsequent entry in the log file for the second server.
- should there be logfile entries on the first server referencing the chain-uri (or on the client ldapsearch with -d1)?
- is there a missing directive or incorrect configuration?
Thanks for any assistance.
Peter
|