[Date Prev][Date Next] [Chronological] [Thread] [Top]

Trouble with slapd-ldap in various scenarios (LdarErr: DSID-0C090627)



Hello,

I'm evaluating OpenLDAP and I've got cornered with slapd-ldap combined together
with slapd-relay or slapo-translucent.

First of all, I would like to mention that I read man pages back and forth.
I also read archives of openldap.org mailing lists as well as configuration
files for slapd tests. I'm still a little bit confused.

The second important thing is that I don't want to enable anonymous binding at
this time. Each user that access slapd is required to bind using its own DN
and credentials. This statement is valid for both kind of repositories -
local or remote.

So, give me a chance, please... ;-)

I tried several scenarios but was only partially successful. You can find
more info about them below.

I read about acl-bind, idassert-bind & idassert-authzFrom, mode=self but
I was not able to get them working so far. I haven't used any 'authz-xxx'
options yet. So, the configuration parts (below) doesn't contain only the
schema includes and the config database settings.

1. What's wrong with my configuration? (cases A & B at first)
I suppose that I had to use idassert-bind somehow but I don't have any idea
how to do it.

2. Why is there the second connection with the strange binding request?
This is probably related with question 1 but it could be an error symptom.
I just want to be sure...

3. Do I have to use something else except "idassert-bind mode=self" option?
I just want to bind to remote server with the proper user DN (my application
is requesting data on behalf of user) and additionaly on some specific
account DN (if the application is requesting data for private use).

I feel that these questions could look silly, but I hope that it's better
to make itself to look like fool, get advice and move forward then stand
still.

Thanks for any advice,
Martin Rubas

PS: I'm sorry for being so long...

#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Notes:
~ using slapd version 2.4.15 on Ubuntu (9.04/jaunty;64-bit;localhost)
- using Windows 2003 Server as PDC (pdc.domain.net)
~ command used to query:
  ldapsearch -x -w secret -H ldap://localhost:389 \
     -D 'CN=The Root,CN=Users,DC=domain,DC=net' \
     -b 'CN=The User,CN=Users,DC=domain,DC=net' \
     -s sub -a always '(objectClass=*)'
~ all used accounts (The Root, The User, The Bind & Administrator) exists
  in Windows domain (AD) and have set password to 'secret'. 'The Root' is
  also member 'Domain Admins', so it should have the same access rights as
  'Administrator' (at least, for AD/LDAP operations)

=== Case A ===

I started with slapd-hdb and slapo-translucent to combine data from
Active Directory repository with other data from local DB. It finally got
it working but only when ldapsearch command was binding with "rootdn" from
slapd-hdb configuration. But I want to do binding with the (proper) user DN
to slapd (local repository) as well as to AD (remote one).

#======================================================================
database    hdb
suffix        "dc=domain,dc=net"
rootdn        "cn=The Root,cn=Users,dc=domain,dc=net"
rootpw        secret
directory    /var/lib/ldap/lib-trans
index objectClass eq
index cn eq

overlay   translucent
uri       ldap://pdc.domain.net:389
binddn    "cn=The Bind,cn=Users,dc=domain,dc=net"
bindpw    heslo
lastmod   off
chase-referrals true
rebind-as-user  true
#----------------------------------------------------------------------

If I use ldapsearch -D "cn=The Root,..." -b "cn=The User,..." then slapd
binds to "cn=The Bind". That's correct, I guess...
But when I use some other DN for -D parameter then  the response is
"LdarErr: DSID-0C090627 ... " (I saw that one many time in archives).
It doesn't matter if it was "cn=The User,..." or "cn=The Bind".

=== Case B ===

I also tried to combine slapd-ldap together with slapd-relay extended by
slapo-rwm, to get something like "domain-alias" (2 names for one repository).

#======================================================================
database        ldap
suffix            "dc=domain,dc=net"
uri       ldap://pdc.domain.net:389
chase-referrals yes
rebind-as-user  yes

database    relay
suffix      "dc=alias,dc=net"
relay       "dc=domain,dc=net"
overlay     rwm
rwm-suffixmassage "dc=domain,dc=net"
#----------------------------------------------------------------------

In this case, I was able to get result with -D option set to
"cn=The User,cn=Users,dc=domain,dc=net" but I got the same error while using
the aliased DN "cn=The Users,cn=Users,dc=alias,dc=net".

=== Case C/D ===
Finally, I gave up and tried most simple case. Plain slapd-ldap (C) and
with slapo-rwm (D). This way I've got simple bridge to AD or an alias for it.

#======================================================================
database        ldap
suffix            "dc=domain,dc=net"   #for C only
#D#suffix       "dc=alias,dc=net"
uri             ldap://pdc.domain.net:389
chase-referrals yes
rebind-as-user  yes

#D#overlay  rwm
#D#rwm-suffixmassage "dc=domain,dc=net"
#----------------------------------------------------------------------

Whoa, it worked!
One small step for me, but ... Hm, pretty useless at the whole scope :-(

=== Network Dump ===

I catched a network packets and noticed some pretty wierd thing...
Each ldapsearch received "LdarErr: DSID-0C090627" there way the same scenario:
  1. slapd opens the connection
  2. slapd binds succefully (mostly with the credentials I wanted to use)
  3. slapd opens another connection
  4. slapd binds again with "nothing" (displayed as "<ROOT>" in Wireshark)
  5. slapd sends request and receives LdapErr
  6. slapd unbinds and closses connection from step 3
  x. other requests are processed repeating step 3 to 6

#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 0.000000    a.b.c.174 -> a.b.c.153 :: 50178 > ldap [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=85650917 TSER=0 WS=6
 2 0.000304    a.b.c.153 -> a.b.c.174 :: ldap > 50178 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
 3 0.000321    a.b.c.174 -> a.b.c.153 :: 50178 > ldap [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=85650917 TSER=0
 4 0.000455    a.b.c.174 -> a.b.c.153 :: bindRequest(1) "cn=The Root,cn=Users,dc=domain,dc=net" simple
 5 0.053060    a.b.c.153 -> a.b.c.174 :: bindResponse(1) success
 6 0.053086    a.b.c.174 -> a.b.c.153 :: 50178 > ldap [ACK] Seq=77 Ack=23 Win=5888 Len=0 TSV=85650930 TSER=7278645
 7 0.058317    a.b.c.174 -> a.b.c.153 :: 50179 > ldap [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=85650932 TSER=0 WS=6
 8 0.058604    a.b.c.153 -> a.b.c.174 :: ldap > 50179 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
 9 0.058622    a.b.c.174 -> a.b.c.153 :: 50179 > ldap [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=85650932 TSER=0
10 0.058746    a.b.c.174 -> a.b.c.153 :: bindRequest(1) "<ROOT>" simple
11 0.058972    a.b.c.153 -> a.b.c.174 :: bindResponse(1) success
12 0.058992    a.b.c.174 -> a.b.c.153 :: 50179 > ldap [ACK] Seq=15 Ack=23 Win=5888 Len=0 TSV=85650932 TSER=7278645
13 0.059158    a.b.c.174 -> a.b.c.153 :: searchRequest(2) "cn=The User,cn=Users,dc=domain,dc=net" wholeSubtree
14 0.059380    a.b.c.153 -> a.b.c.174 :: searchResDone(2) operationsError (00000000: LdapErr: DSID-0C090627, comment: ...)
15 0.098978    a.b.c.174 -> a.b.c.153 :: 50179 > ldap [ACK] Seq=140 Ack=196 Win=6912 Len=0 TSV=85650942 TSER=7278645
16 225.873049  a.b.c.174 -> a.b.c.153 :: unbindRequest(3)
17 225.873111  a.b.c.174 -> a.b.c.153 :: 50179 > ldap [FIN, ACK] Seq=147 Ack=196 Win=6912 Len=0 TSV=85707385 TSER=7278645
18 225.873183  a.b.c.174 -> a.b.c.153 :: unbindRequest(2)
19 225.873227  a.b.c.174 -> a.b.c.153 :: 50178 > ldap [FIN, ACK] Seq=84 Ack=23 Win=5888 Len=0 TSV=85707385 TSER=7278645
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For case A the steps 1 & 2 happens when translucent_bind action is executed
(for the first time) and the step 3-6 are related to translucent_search action.
I didn't check those for case B.

Each successful request is processed the following way:
  1. slapd opens the connection
  2. slapd binds succefully (mostly with the credentials I wanted to use)
  3. slapd sends request and receives the requested data
  4. slapd unbinds and closses connection from step 1