[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Referral questions
Hi,
I have an OpenLDAP 2.1.3 server with SASL/GSSAPI and OpenSSL (StartTLS)
enabled, but I have some problems dealing with referrals. Forgive me for
this being a bit on the lengthy side, I wanted to make sure that things
were explained clearly and that all of my questions are answered.
First off, what does Manage DSA IT control do? What do all the acronyms
stand for? I understand passing the -M parameter gives me the referral
object itself, without actually having the server refer the client to
where it points. I.E., so I can modify, view or delete the object itself
on the superior server. Is there any other purpose to -M? Does it ever
make sense to pass both -C and -M to ldapsearch? What would this do?
My intentions are to have ou=Folks,o=maly.net refer to
ou=People,o=maly.net , on the same server. My server is named
ldap.maly.net . Here is what I get:
-------------------
$ ldapsearch -ZZ -M -b ou=Folks,o=maly.net '*' ref
SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# filter: (objectclass=*)
# requesting: * ref
# with manageDSAit control
#
# Folks, maly.net
dn: ou=Folks,o=maly.net
objectClass: extensibleObject
objectClass: referral
ref: ldap://ldap.maly.net/ou=People,o=maly.net
------------
That basically shows the LDIF I entered when adding the referral (I
actually added it via GQ, but that's besides the point).
Why do I need to specify "ref" as the last parameter? From what I
understand, omitting which attributes to list should return all of them,
correct? I have that work fine and dandy with other objects, oddly.
Here is the object that I would like to ultimately get back, which is
what the referral should point to (rather, point to the OU above this
object, having ou=Folks,o=maly.net -> ou=People,o=maly.net):
------------
$ ldapsearch -ZZ -b ou=People,o=maly.net uid=tmaly
SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# filter: uid=tmaly
# requesting: ALL
#
# tmaly, People, maly.net
dn: uid=tmaly,ou=People,o=maly.net
objectClass: top
objectClass: posixAccount
objectClass: person
loginShell: /bin/bash
uid: tmaly
uidNumber: 10000
gidNumber: 10000
homeDirectory: /home/tmaly
gecos: Tomas Maly
sn: Maly
userPassword:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
cn: Tomas Maly
------------
Now, if I try to pass -C to ldapsearch (and omit the -M), to chase the
referral (i.e., query the referring server) and try to search under the
ou=Folks,o=maly.net base, it seems to stall and return nothing. At best,
ldapsearch will stop within a few minutes. What gives? What am I doing
wrong here?
Now, I noticed slapd.log with lines like this, being generated every
second or less (I have slapd write this to the log file at least several
hundreds or thousands of times while I have ldapsearch waiting for reslts):
-------------
Jul 24 15:18:52 dx2-50 slapd[6482]: conn=1 op=1812 SRCH
base="ou=Folks,o=maly.net" scope=2 filter="(uid=tmaly)"
Jul 24 15:18:52 dx2-50 slapd[6483]: conn=1 op=1811 RESULT tag=101 err=10
text=
------------
Hmmmm, any significance? From immediately below, I notice that it says
"result: 10 Referral", hinting at error code "10" meaning "Referral".
This sounds like a long shot, but it seems like I'm being referred to
itself, and I'm in an infinite loop. I also noticed this, which is even
more odd.
------------
$ ldapsearch -ZZ -b ou=Folks,o=maly.net uid=tmaly
SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# filter: uid=tmaly
# requesting: ALL
#
# search result
search: 6
result: 10 Referral
matchedDN: ou=Folks,o=maly.net
ref: ldap://ldap.maly.net/ou=Folks,o=maly.net??sub
------------
Obviously, this should just return the referral. But notice how it
refers to itself! What gives?
When I try to use GQ, I get two instances of ou=People,o=maly.net
displayed. I'm guessing that it's working dandy in that situation.
Now, I noticed that doing the following returns results I would expect:
-------------------
$ ldapsearch -M -ZZ -b ou=Persons,o=maly.net -s base
'objectClass=referral' ref
SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# filter: objectClass=referral
# requesting: ref
# with manageDSAit control
#
# Persons, maly.net
dn: ou=Folks,o=maly.net
ref: ldap://ldap.maly.net/ou=People,o=maly.net??sub
----------------
That's exactly what I want! If I exclude the -M this time, or if I
search below ou=Folks,o=maly.net, I get the self-referencing referral.
WHY!?!?!? Sounds confusing. There is no instance in which it returns a
proper referral. At best, I can get the above case, but of course that's
useless.
When I set the search scope via -s, it puts that into the
self-referencing referral. However, when I pass attributes to return or
a filter, it does not insert that into the referral's result. If that is
intended, why?
Also, I have in slapd.conf a line saying "security ssf=160". Normally,
the -ZZ passed to ldapsearch fixes that (I have a server certificate on
the server side, and the certificate of the signing CA on the client
side), but when I try to chase the referral, this happens:
-----------
$ ldapsearch -ZZ -C -b ou=Folks,o=maly.net uid=tmaly
SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# filter: uid=tmaly
# requesting: ALL
#
# search result
search: 6
result: 13 Confidentiality required
text: confidentiality required
# numResponses: 1
--------------
If I disable the security requirement in slapd.conf, it works fine. What
gives? I want to mandate StartTLS for security reasons. Like I said, it
works fine, but only when not referencing referrals.
I suspect that if I look at the code, I might be able to figure some of
this out, so I shall. I'd appreciate help from seasoned professionals
(and/or the developers), though.
Thanks so much for your help.
Tomas Maly