Hi again,

I forgot to answer my own question when I finally solved it. For whatever reason, the openldap proxy did not want to connect properly to the back-end AD using LDAPS on port 636, but it worked with LDAP+TLS on port 389.

this is the log part where AD said "no thanks", solved by using LDAP/TLS instead of LDAPS:

TLS trace: SSL_connect:SSLv3 write client hello A tls_read: want=5 error=Connection reset by peer TLS trace: SSL_connect:error in SSLv3 read server hello A TLS: can't connect: .

Then, the order of my config including "subordinate" and "idassert-authzFrom" was as well not completely correct. Anyway, I recommend to remove SSL/TLS until everything works, it allows for sniffing/tcpdump/etc. When you have all your functionality working, turn on SSL/TLS, it will most likely break somewhere (certs, etc). Fix, and there you are.

I invested several days until everything was working. With the added pain that you cnanot easily disabled SSL on Windows, nor export its private key to load into Wireshark because in their infinite wisdom, Micro$oft decided people shall not be able to export private keys. In retrospect, this project part was a major pain and we violated the budget and work estimation by a factor of 2 or 3.

The next big problem was the non-support of LDAP_MATCHING_RULE_IN_CHAIN by OpenLDAP. With the help of very nice people from this list, I was able to add a small module (mr_passthru) to my config. See my email traffic from June 3-6 about that.

In the hope it will help someone, here is a close-copy of my existing config : http://pastebin.com/qZB5757H

Now if you embark into building such a proxy, be ready to read the manpage and the code, and have plenty of time :-)

Fair wind, Charles

On 05.05.14 16:34, Charles Bueche wrote:

Hi,

I have an OpenLDAP proxy using back_meta to talk to two back-ends Microsoft AD servers. My goal is to provide a single view of both AD trees.

Basically, it works, as long as I use a bind account which exists in one of the back-end AD's.

However, to first search where an AD account is, I would like to use a local account on the LDAP proxy. To my understanding, I need to use

database meta suffix dc=proxy,dc=stuff,dc=ch rootdn "cn=root,dc=proxy,dc=stuff,dc=ch" rootpw "secret" subordinate

...

idassert-bind bindmethod=simple binddn="CN=srvLDAP,..." credentials="..." mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=root,dc=proxy,dc=stuff,dc=ch"

The DN "cn=root,dc=proxy,dc=stuff,dc=ch" does exist in the proxy and can do local searches. However, the account defined in the idassert is never used, and the connections to the back-ends AD's fail. Respectively, I think they are contacted using anonymous instead of the account I specify (not sure about the anonymous part, the debug log isn't very clear about it).

Hints welcome. Below is a part of the relevant log if it helps.

Charles

.......... tls_read: want=64, got=64 0000: 65 87 ac 08 7e 49 8d 7f 95 3c d0 1f 09 57 b7 ce e...~I...<...W.. 0010: d4 13 2e ac 57 c9 27 6b 58 f7 76 70 a1 95 10 3e ....W.'kX.vp...> 0020: e2 96 0d cf a1 d3 13 ff e7 0b b1 2f c0 6f dc 19 .........../.o.. 0030: 93 38 07 b9 f7 e4 81 a8 e0 45 0e 97 ec 7f 21 a6 .8.......E....!. TLS trace: SSL_connect:SSLv3 read finished A ldap_int_poll: fd: -1 tm: 0 53679e3b conn=1000 op=1 <<< meta_search_dobind_init[0]=4 53679e3b conn=1000 op=1 <<< meta_back_search_start[0]=4 53679e3b conn=1000 op=1 meta_back_search: ncandidates=1 cnd="*" 53679e3b conn=1000 op=1 >>> meta_search_dobind_init[0] ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 12 tm: 0 ldap_is_sock_ready: 12 ldap_ndelay_off: 12 TLS trace: SSL_connect:before/connect initialization tls_write: want=225, written=225 0000: 16 03 01 00 dc 01 00 00 d8 03 02 53 67 9e 3b 55 ...........Sg.;U 0010: 4b 2f ee 53 01 81 ee ca 6a 3f a0 ea 85 3a c9 7e K/.S....j?...:.~ 0020: e3 01 d7 e6 d1 09 65 14 21 05 ef 00 00 66 c0 14 ......e.!....f.. 0030: c0 0a c0 22 c0 21 00 39 00 38 00 88 00 87 c0 0f ...".!.9.8...... 0040: c0 05 00 35 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 ...5............ 0050: 00 13 c0 0d c0 03 00 0a c0 13 c0 09 c0 1f c0 1e ................ 0060: 00 33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 .3.2.....E.D.... 0070: 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 ./...A.......... 0080: 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 ................ 0090: 00 03 00 ff 01 00 00 49 00 0b 00 04 03 00 01 02 .......I........ 00a0: 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c ...4.2.......... 00b0: 00 18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 ................ 00c0: 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 ................ 00d0: 00 03 00 0f 00 10 00 11 00 23 00 00 00 0f 00 01 .........#...... 00e0: 01 . TLS trace: SSL_connect:SSLv3 write client hello A tls_read: want=5 error=Connection reset by peer TLS trace: SSL_connect:error in SSLv3 read server hello A TLS: can't connect: . ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 12 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7 error=Broken pipe ldap_free_connection: actually freed 53679e3b conn=1000 op=1 <<< meta_search_dobind_init[0]=0 53679e3b send_ldap_result: conn=1000 op=1 p=3 53679e3b send_ldap_result: err=0 matched="" text="" 53679e3b send_ldap_result: conn=1000 op=1 p=3 53679e3b send_ldap_result: err=0 matched="" text="" 53679e3b send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 14 bytes to sd 11 0000: 30 0c 02 01 02 65 07 0a 01 00 04 00 04 00 0....e........ tls_write: want=69, written=69