Re: idassert-authzFrom ignored

[Charles Bueche <cblists@bueche.ch>]

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