Re: ManageDSAiT

[Pierangelo Masarati <ando@sys-net.it>]

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