ManageDSAiT

[Christophe Gudin]

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.

[Pierangelo Masarati]

Post by Christophe Gudin
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.

Post by Christophe Gudin
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectClass=*)
# requesting: supportedControl
#
#
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.

Post by Christophe Gudin
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.

Post by Christophe Gudin
The referrals aren't
followed

Again, manageDSAit has nothing to do with "following referrals".

Post by Christophe Gudin
and I have the following logged error and no result is returned
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]: 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.

Post by Christophe Gudin
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: [phone]
Mobile: [phone]
Email: ***@sys-net.it
---------------------------------------

[Michael Ströder]

Post by Pierangelo Masarati

Post by Christophe Gudin
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.