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: [EMAIL PROTECTED] ---------------------------------------
