Hello list,
I'm having some trouble with following referrals and especially ManageDSAiT.
When I request the supported controls here's what I get:
# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectClass=*) # requesting: supportedControl #
# dn: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
So the ManageDSAiT (2.16.840.1.113730.3.4.2) is meant to be supported. However if I try any search (or add, etc) with the -M parameter (or if I use JNDI where I believe this control is set by default) The referrals aren't followed and I have the following logged error and no result is returned (not even a referral record): Jul 18 11:45:03 linuxAeL1 slapd[4163]: begin get_filter Jul 18 11:45:03 linuxAeL1 slapd[4163]: EQUALITY Jul 18 11:45:03 linuxAeL1 slapd[4163]: end get_filter 0 Jul 18 11:45:03 linuxAeL1 slapd[4163]: filter: (uid=jlsteiner1000f) Jul 18 11:45:03 linuxAeL1 slapd[4163]: => get_ctrls Jul 18 11:45:03 linuxAeL1 slapd[4163]: => get_ctrls: oid=" 2.16.840.1.113730.3.4.2" (noncritical) Jul 18 11:45:03 linuxAeL1 slapd[4163]: <= get_ctrls: n=1 rc=0 err="" Jul 18 11:45:03 linuxAeL1 slapd[4163]: attrs: Jul 18 11:45:03 linuxAeL1 slapd[4163]: Jul 18 11:45:03 linuxAeL1 slapd[4163]: conn=41 op=1 SRCH base="o=EtatGE,c=CH" scope=2 deref=3 filter="(uid=jlsteiner1000f)" Jul 18 11:45:03 linuxAeL1 slapd[4163]: slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2
I really don't understand why this last line is coming up.
I configured openLDAP with the followings: ./configure --enable-backends --enable-overlays --enable-tls --enable-acl
Here's my slapd.conf:
# NOTES: inetorgperson picks up attributes and objectclasses # from all three schemas # # NB: RH Linux schemas in /etc/openldap #
include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openca.schema include /usr/local/etc/openldap/schema/ldappc.schema include /usr/local/etc/openldap/schema/kitneduperson.schema
# DON'T bother with ARGS file unless you feel strongly # slapd scripts stop scripts need this to work pidfile /var/run/slapd.pid
# enable a lot of logging - we might need it # but generates huge logs #loglevel Conns Sync Filter loglevel -1
# NO dynamic backend modules
# TLS-enabled connections TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /usr/local/var/openldap-data/cacert.pem TLSCertificateFile /usr/local/var/openldap-data/ldapcrt.pem TLSCertificateKeyFile /usr/local/var/openldap-data/ldapkey.pem
#Here I added the chaining
overlay chain
####################################################################### # bdb database definitions # # replace example and com below with a suitable domain # # If you don't have a domain you can leave it since example.com # is reserved for experimentation or change them to my and inc # ####################################################################### database monitor access to dn.subtree=cn=monitor by dn.exact=cn=Manager,o=example,c=ch write by dn.subtree=o=example,c=ch read by * write
database bdb suffix "o=example,c=ch" # root or superuser rootdn "cn=Manager,o=example,c=ch"
rootpw secret # The database directory MUST exist prior to running slapd AND # change path as necessary directory /usr/local/var/openldap-data
# Indices to maintain for this directory # unique id so equality match only index uid eq # allows general searching on commonname, givenname and email index cn,gn,mail eq,sub # allows multiple variants on surname searching #index sn eq,sub # sub above includes subintial,subany,subfinal # optimise department searches #index ou eq # if searches will include objectClass uncomment following # index objectClass eq # shows use of default index parameter index default eq,sub
# other database parameters # read more in slapd.conf reference section cachesize 10000 checkpoint 128 15
dbconfig set_cachesize 0 30000000 0 dbconfig set_lg_bsize 3000000 dbconfig set_flags DB_LOG_AUTOREMOVE
dbcachesize 350000
Also as an aside question, I'm not sure I understand why the server is doing the recursion referral correctly (i.e. it returns the correct record fetched on the second server instead of the referral record) when I *don't* put the -M option...
As I'm a little lost in those referral questions and I didn't find relevant information I hope someone can clarify this for me.
Best,
Christophe.
Christophe Gudin wrote:
Hello list,
I'm having some trouble with following referrals and especially ManageDSAiT.
ManageDSAit has no use in "following referrals"; actually, it's meant to provide the opposite, i.e. access to the real referral entry rather then it being used to "compute" a referral (or search references). Please refer to RFC 3296.
When I request the supported controls here's what I get:
# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectClass=*) # requesting: supportedControl #
# dn: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
So the ManageDSAiT (2.16.840.1.113730.3.4.2) is meant to be supported.
This means it is __recognized__. In fact, returning LDAP_UNWILLING_TO_PERFORM when a control is marked as critical, or ignoring it when it's not is a perfectly compliant manner of supporting any recognized control.
However if I try any search (or add, etc) with the -M parameter (or if I use JNDI where I believe this control is set by default)
Using manageDSAit by default is an abuse of that control, since its use is confined to very specific needs (like administering a DIT); I wouldn't assume this happens by default in any piece of software. Having said this, I have no knowledge of JNDI.
The referrals aren't followed
Again, manageDSAit has nothing to do with "following referrals".
and I have the following logged error and no result is returned (not even a referral record): Jul 18 11:45:03 linuxAeL1 slapd[4163]: begin get_filter Jul 18 11:45:03 linuxAeL1 slapd[4163]: EQUALITY Jul 18 11:45:03 linuxAeL1 slapd[4163]: end get_filter 0 Jul 18 11:45:03 linuxAeL1 slapd[4163]: filter: (uid=jlsteiner1000f) Jul 18 11:45:03 linuxAeL1 slapd[4163]: => get_ctrls Jul 18 11:45:03 linuxAeL1 slapd[4163]: => get_ctrls: oid=" 2.16.840.1.113730.3.4.2" (noncritical) Jul 18 11:45:03 linuxAeL1 slapd[4163]: <= get_ctrls: n=1 rc=0 err="" Jul 18 11:45:03 linuxAeL1 slapd[4163]: attrs: Jul 18 11:45:03 linuxAeL1 slapd[4163]: Jul 18 11:45:03 linuxAeL1 slapd[4163]: conn=41 op=1 SRCH base="o=EtatGE,c=CH" scope=2 deref=3 filter="(uid=jlsteiner1000f)" Jul 18 11:45:03 linuxAeL1 slapd[4163]: slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2
This is an informative message (you need a very specific debug level to see it) which tells the manageDSAit control is not managed by the frontend. In fact, any time it's managed, backends take care of it.
Also as an aside question, I'm not sure I understand why the server is doing the recursion referral correctly (i.e. it returns the correct record fetched on the second server instead of the referral record) when I *don't* put the -M option...
As I'm a little lost in those referral questions and I didn't find relevant information I hope someone can clarify this for me.
See above.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Christophe Gudin wrote:
I'm having some trouble with following referrals and especially ManageDSAiT.
ManageDSAit has no use in "following referrals"; actually, it's meant to provide the opposite, i.e. access to the real referral entry rather then it being used to "compute" a referral (or search references). Please refer to RFC 3296. [..] Using manageDSAit by default is an abuse of that control, since its use is confined to very specific needs (like administering a DIT); I wouldn't assume this happens by default in any piece of software. Having said this, I have no knowledge of JNDI.
Well, some people might be inspired in the wrong direction because of JNDI's behaviour. They send the ManageDSAit control by default and extract the search continuation information from the referral entries received.
Ciao, Michael.
openldap-software@openldap.org
-
Christophe Gudin -
Michael Ströder -
Pierangelo Masarati