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 ---------------------------------------