Marcos Ares Troubleshooting Weblog

Any simple LDAP SRCH request which is addressed to my Directory Proxy Server port (port 15000) AND run against my suffix (o=migration) when binding as one user under the o=migration suffix will succesfully cross through the DPS and get till the DS backend, here is an example:

mares $ ldapsearch -p 15000 -D "uid=cnewport, ou=People, o=migration" -w secret12 -b "o=migration" cn=* dn
ldap_simple_bind: Invalid credentials
mares $

Note that I received error=32 (invalid credentials) because I did not provide the good credentials for uid=cnewport in the ldapsearch command line, but THE POINT IS the operation travels through the DPS towards the DS (see the SERVER_OP messages below extracted from the DPS access log):

[07/Jun/2007:16:48:49 +0200] - CONNECT - INFO - conn=4 client=127.0.0.1:64601 server=localhost:15000 protocol=LDAP
[07/Jun/2007:16:48:49 +0200] - PROFILE - INFO - conn=4 assigned to connection handler cn=default connection handler, cn=connection handlers, cn=config
[07/Jun/2007:16:48:49 +0200] - OPERATION - INFO - conn=4 op=0 BIND dn="uid=cnewport,ou=people,o=migration" method="SIMPLE" version=3
[07/Jun/2007:16:48:49 +0200] - SERVER_OP - INFO - conn=4 op=0 BIND dn="uid=cnewport, ou=People, o=migration" method="SIMPLE"" version=3 s_msgid=2 s_conn=france:9
[07/Jun/2007:16:48:49 +0200] - SERVER_OP - INFO - conn=4 op=0 BIND RESPONSE err=49 msg="" s_conn=france:9
[07/Jun/2007:16:48:49 +0200] - OPERATION - INFO - conn=4 op=0 BIND RESPONSE err=49 msg="" etime=0
[07/Jun/2007:16:48:49 +0200] - OPERATION - INFO - conn=4 op=1 UNBIND
[07/Jun/2007:16:48:49 +0200] - DISCONNECT - INFO - conn=4 reason="unbind"

If I execute the same simple SRCH on my suffix o=migration binding as cn=directory manager and send it once again to my DPS (port 15000), it will NOT succesfully cross through the DPS and therefore, it will NOT get to the DS backend:

mares $ ldapsearch -p 15000 -D "cn=directory Manager" -w secret12 -b "o=migration" cn=* dn
ldap_simple_bind: No such object
mares $

Here is the DPS access snippet in this case, the absence of SERVER_OP bits proves no DS interaction:

[07/Jun/2007:16:46:26 +0200] - CONNECT - INFO - conn=3 client=127.0.0.1:64596 server=localhost:15000 protocol=LDAP
[07/Jun/2007:16:46:26 +0200] - PROFILE - INFO - conn=3 assigned to connection handler cn=default connection handler, cn=connection handlers, cn=config
[07/Jun/2007:16:46:26 +0200] - OPERATION - INFO - conn=3 op=0 BIND dn="cn=directory manager" method="SIMPLE" version=3
[07/Jun/2007:16:46:26 +0200] - OPERATION - INFO - conn=3 op=0 BIND RESPONSE err=32 msg="" etime=0
[07/Jun/2007:16:46:26 +0200] - OPERATION - INFO - conn=3 op=1 UNBIND
[07/Jun/2007:16:46:26 +0200] - DISCONNECT - INFO - conn=3 reason="unbind"

Note that in this case, the DPS receives the BIND and it never tries to route it to any backend DS server, as cn=Directory Manager does not respond to any particular suffix. Therefore, the DPS tries to find it locally, but does not find it and returns an error 32.

So, the question is:

How can I cross cn=Directory Manager through the DPS?

The DSEE Admin Guide provides the answer, page 408:

"Note – You must use the credentials of a user under dc=example,dc=com. If you want to use cn=Directory Manager, you must define a data view to handle that DN."

In the DSCC DPS console, it is straight forward to add a new Data View for cn=directory Manager. You may need to include a reference to such a new view in your Connection Handler configuration as well to inform the connection handler in place that ant request matching that particular data view would need to be forwarded.

Once that new definition is in place, a new execution of the previous failing SRCH should work this time:

mares $ ldapsearch -p 15000 -D "cn=directory Manager" -w secret12 -b "o=migration" cn=* dn
version: 1
dn: cn=Directory Administrators, o=migration
dn: uid=a111,o=migration
dn: uid=ugaston,o=migration
dn: uid=mares,o=migration
dn: uid=jvergara,o=migration
...
...
...

The corresponding DPS access log shows the SERVER_OP bits this time:

[07/Jun/2007:17:15:25 +0200] - CONNECT - INFO - conn=31 client=127.0.0.1:648
51 server=localhost:15000 protocol=LDAP
[07/Jun/2007:17:15:25 +0200] - PROFILE - INFO - conn=31 assigned to connecti
on handler cn=default connection handler, cn=connection handlers, cn=config
[07/Jun/2007:17:15:25 +0200] - OPERATION - INFO - conn=31 op=0 BIND dn="cn=dir
ectory manager" method="SIMPLE" version=3
[07/Jun/2007:17:15:25 +0200] - SERVER_OP - INFO - conn=31 op=0 BIND dn="cn=dir
ectory Manager" method="SIMPLE"" version=3 s_msgid=2 s_conn=france:1
[07/Jun/2007:17:15:25 +0200] - SERVER_OP - INFO - conn=31 op=0 BIND RESPONSE e
rr=0 msg="" s_conn=france:1
[07/Jun/2007:17:15:25 +0200] - PROFILE - INFO - conn=31 assigned to connecti
on handler cn=migration,cn=connection handlers,cn=config
[07/Jun/2007:17:15:25 +0200] - OPERATION - INFO - conn=31 op=0 BIND RESPONSE e
rr=0 msg="" etime=0
[07/Jun/2007:17:15:25 +0200] - OPERATION - INFO - conn=31 op=1 msgid=2 SEARCH
base="o=migration" scope=2 filter="(cn=*)" attrs="dn "
[07/Jun/2007:17:15:25 +0200] - SERVER_OP - INFO - conn=31 op=-1 BIND dn="cn=di
rectory manager" method="SIMPLE"" version=3 s_msgid=3 s_conn=france:1
[07/Jun/2007:17:15:25 +0200] - SERVER_OP - INFO - conn=31 op=-1 BIND RESPONSE
err=0 msg="" s_conn=france:1
[07/Jun/2007:17:15:25 +0200] - SERVER_OP - INFO - conn=31 op=1 SEARCH base="o=
migration" scope=2 filter="(cn=*)" attrs="dn " s_msgid=4 s_conn=france:1
[07/Jun/2007:17:15:25 +0200] - SERVER_OP - INFO - conn=31 op=1 SEARCH RESPONSE
err=0 msg="" nentries=163 s_conn=france:1
[07/Jun/2007:17:15:25 +0200] - OPERATION - INFO - conn=31 op=1 SEARCH RESPONSE
err=0 msg="" nentries=163 etime=500
[07/Jun/2007:17:15:25 +0200] - OPERATION - INFO - conn=31 op=2 UNBIND
[07/Jun/2007:17:15:25 +0200] - DISCONNECT - INFO - conn=31 reason="unbind"