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
Hi,
Martin Rubáš mrubas@kerio.com writes:
Hello,
[...]
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".
This Error seems to be not a slapd error, so you should check some other services in your network. The configuration parameters for translucent overlay are incorrect, see man slapo-translucent(5) and man slapd-ldap(5), you should probably use idassert-bind parameters.
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".
In the first case you where requesting the ldap backend, in the second case the relay backend. If a request to relay backend failed but where successful to the ldap backend, than something is wrong with your relay backend configuration. Debug slapd's acl parsing to find the reason.
[...]
-Dieter
Thanks for your reponse, Dieter. Basically, you said "RTFM" just using more polite words. But I already do that, man! I played with a few combination of idassert-bind option but it doesn't help to me. B-)
Dieter Kluenter wrote:
Martin Rubáš mrubas@kerio.com writes:
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".
This Error seems to be not a slapd error, so you should check some other services in your network. The configuration parameters for translucent overlay are incorrect, see man slapo-translucent(5) and man slapd-ldap(5), you should probably use idassert-bind parameters.
Yes, I know that this error is returned by Active Directory LDAP server. It says, that data were requested using unbinded connection and AD server on Win2003 requires to bind. See the second half of this (and also the original email)...
#====================================================================== 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 the first case you where requesting the ldap backend, in the second case the relay backend. If a request to relay backend failed but where successful to the ldap backend, than something is wrong with your relay backend configuration. Debug slapd's acl parsing to find the reason.
"man slapd-relay" shows only one option that I already used - relay <real.naming.ctx>. other option mentioned in "man slapd.conf" under section related to backends doesn't talk about anything related to binding (except sync-replication which is no matter now).
---
If I understood man pages and FAQs well the identity assertion mechanism allows to specify (through idassert-bind, idassert-authzFrom, etc.) which identity will be used to bind on remote server. As I want to use the identity that was used to access slapd I have to use idassert-bind with mode=self or mode=legacy. That's correct, isnt't?
So, what's wrong with my config that binding to raw ldap backend works and binding to relay doesn't (yes, I use proper DNs with correct suffix):
1. ldapsearch ... -D "cn=The User,cn=Users,dc=domain,dc=net" - is successful and TCP stream looks something like that: connect(srcport=44111) bind(44111)["The User"] -> success request(44111) -> success
2. ldapsearch .... -D "cn=The User,cn=Users,dc=alias,dc=net" - ends with failure and TCP stream is pretty weird: connect(44111) bind(44111)["The User"] -> success connect(33666) --- why??? bind(33666)["<ROOT>"] -> success --- huh ??? anonymous bind??? request(33666) -> LdapErr: DSID-0C090627 --- no-binding = no-data from Active Directory
... and consecutive searches are similar to this one:
connect(44222) --- another connection??? why??? the 44111 was not closed yet... bind(44222)["The User"] -> success request(33666) -> LdapErr: DSID-0C090627 --- reusing incorrectly binded connection?? very nice :-(
For more details on TCP stream see original email (there is a packet dump from Wireshark).
So, what I have not been able to do yet... I want to use the slapd with "The User" and its own credentials to forward LDAP request to remote Active Directory with the identity of "The User" using slapd-relay/slapo-rwm or slapd-hdb/slapo-translucent exactly same way as it works for raw slapd-ldap.
The only way was to specify some account using idassert-bind. The search through slapd-relay returned the requested data but the "doubled connection" was still in play but "The IdAssert" identity was used instead of the strange "<ROOT"> for binding. Unfortunately, this is not desired but "The User" biding is preferred.
I hope I explained my problem well. Could someone help me, please?
Martin
Martin Rubáš mrubas@kerio.com writes:
Thanks for your reponse, Dieter. Basically, you said "RTFM" just using more polite words. But I already do that, man! I played with a few combination of idassert-bind option but it doesn't help to me. B-)
All I want to achieve is, that you yourself will understand the process and the relevant configuration parameters. Just posting a few configuration parameters wouldn't help you much.
[...] I am not so much interested on what is going over the wire to AD, I am much more interested in debugging slapd, as this will show what data is received from a client and send to the server. This will hopefully show you what is going wrong.
[...]
So, what I have not been able to do yet... I want to use the slapd with "The User" and its own credentials to forward LDAP request to remote Active Directory with the identity of "The User" using slapd-relay/slapo-rwm or slapd-hdb/slapo-translucent exactly same way as it works for raw slapd-ldap.
[...] I quite understood your requirements.
-Dieter
openldap-technical@openldap.org
-
Dieter Kluenter -
Martin Rubáš