Multiple ldaps (SSL) backends and only the first queried works. Possible bug?
I've two ldaps backends instantiated like: authorize { ... Autz-Type OPENLDAP { openldap } Autz-Type ADLDAP { adldap } ... } authenticate { ... Auth-Type OPENLDAP { openldap } Auth-Type ADLDAP { adldap } ... } The two modules are configured as follows using DIFFERENT issuing CAs... ldap adldap { server = "ldaps://myAD.ds.units.it" identity = ... password = ... basedn = ... filter = "(samaccountname=%{%{Stripped-User-Name}:-%{User-Name}})" ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 tls { start_tls = no cacertfile = /usr/local/etc/raddb/.../certs/ad_root_ca.pem require_cert = "demand" } ... } ldap openldap { server = "ldaps://myopenldap.units.it" identity = ... password = ... basedn = ... filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" ldap_connections_number = 5 timeout = 5 timelimit = 5 net_timeout = 10 tls { start_tls = no cacertfile = /etc/ssl/certs/AddTrust_External_Root.pem require_cert = "demand" } ... } Now, the problem is that once I started freeradius, the first connection to an ldap server goes straight, while the second (to the other one) says: ldap_create ldap_url_parse_ext(ldaps://myAD.ds.units.it) ldap_bind ldap_simple_bind ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP myAD.ds.units.it:636 ldap_new_socket: 32 ldap_prepare_socket: 32 ldap_connect_to_host: Trying yyy.yyy.yyy.yyy:636 ldap_pvt_connect: fd: 32 tm: 1 async: 0 ldap_ndelay_on: 32 ldap_int_poll: fd: 32 tm: 1 ldap_is_sock_ready: 32 ldap_ndelay_off: 32 ldap_pvt_connect: 0 TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code). ldap_err2string ...and letting the first request to be to the myAD server (soon after a restart): ldap_create ldap_url_parse_ext(ldaps://myopenldap.units.it) ldap_bind ldap_simple_bind ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP myopenldap.units.it:636 ldap_new_socket: 33 ldap_prepare_socket: 33 ldap_connect_to_host: Trying xxx.xxx.xxx.xxx:636 ldap_pvt_connect: fd: 33 tm: 10 async: 0 ldap_ndelay_on: 33 ldap_int_poll: fd: 33 tm: 10 ldap_is_sock_ready: 33 ldap_ndelay_off: 33 ldap_pvt_connect: 0 TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code). ldap_err2string I suspect the "cacertfile" attribute is not correctly re-instantiated and only the value of the first request is used to check against when instantiating a new ldaps connection. Any suggestions? -- Daniele ALBRIZIO - albrizio@univ.trieste.it
On 03/05/11 19:00, Daniele Albrizio wrote:
I've two ldaps backends instantiated like:
Forgot... Using compiled freeradius-server-2.1.10 on Debian GNU/Linux 6.0 -- Daniele ALBRIZIO - albrizio@univ.trieste.it Tel. +39-040.558.3319 UNIVERSITY OF TRIESTE - Network Services Divisione V - Infrastrutture e Servizi Informativi via Alfonso Valerio, 12 I-34127 Trieste, Italy Sezione Infrastrutture Informatiche e Telematiche
Daniele Albrizio <albrizio@univ.trieste.it> wrote:
I suspect the "cacertfile" attribute is not correctly re-instantiated and only the value of the first request is used to check against when instantiating a new ldaps connection.
Without a doubt the chaining is not working on your LDAP servers. What is the full output of: openssl s_client -connect myAD.ds.units.it:636 -showcerts openssl s_client -connect myopenldap.units.it:636 -showcerts You can pipe the server cert (cut'n'paste on stdin) through the following to see the useful parts of the certs: openssl x509 -noout -text You probably will find if you change those tls 'demands' to 'never' things work, but then it kinda is self defeating :) Cheers -- Alexander Clouter .sigmonster says: You can't break eggs without making an omelet.
On 03/05/11 21:41, Alexander Clouter wrote:
Daniele Albrizio <albrizio@univ.trieste.it> wrote:
I suspect the "cacertfile" attribute is not correctly re-instantiated and only the value of the first request is used to check against when instantiating a new ldaps connection.
Without a doubt the chaining is not working on your LDAP servers. What
What I suspect is that this is not working with ANY ldap servers as long as you have multiple ldaps backend configured and ldap servers are secured by SSL certificates signed by different CAs
is the full output of:
openssl s_client -connect myAD.ds.units.it:636 -showcerts openssl s_client -connect myopenldap.units.it:636 -showcerts
http://pastebin.com/kyb34c9M for the first http://pastebin.com/Kqd12KQL for the second
You can pipe the server cert (cut'n'paste on stdin) through the following to see the useful parts of the certs:
openssl x509 -noout -text
Yes, perhaps the problem is not whether the verification is successful or not (it works on each server only if we are in the first ldaps conection n a freshly started freeradius), but what happens if the Nth request with N != 1st goes to the other ldap server. This Nth request fails with TLS: peer cert untrusted or revoked (0x42) but it is configured correctly. I suspect this could be a bug in the way multiple CA cert attribute of subsequent requests are handled in freeradius code.
You probably will find if you change those tls 'demands' to 'never' things work, but then it kinda is self defeating :)
Obviously, I don't want that :) -- Daniele ALBRIZIO
On 04/05/11 09:37, Daniele Albrizio wrote:
On 03/05/11 21:41, Alexander Clouter wrote:
Daniele Albrizio<albrizio@univ.trieste.it> wrote:
I suspect the "cacertfile" attribute is not correctly re-instantiated and only the value of the first request is used to check against when instantiating a new ldaps connection.
Without a doubt the chaining is not working on your LDAP servers. What
What I suspect is that this is not working with ANY ldap servers as long as you have multiple ldaps backend configured and ldap servers are secured by SSL certificates signed by different CAs
is the full output of:
openssl s_client -connect myAD.ds.units.it:636 -showcerts openssl s_client -connect myopenldap.units.it:636 -showcerts
http://pastebin.com/kyb34c9M for the first http://pastebin.com/Kqd12KQL for the second
You can pipe the server cert (cut'n'paste on stdin) through the following to see the useful parts of the certs:
openssl x509 -noout -text
Yes, perhaps the problem is not whether the verification is successful or not (it works on each server only if we are in the first ldaps conection n a freshly started freeradius), but what happens if the Nth request with N != 1st goes to the other ldap server. This Nth request fails with TLS: peer cert untrusted or revoked (0x42) but it is configured correctly.
I suspect this could be a bug in the way multiple CA cert attribute of subsequent requests are handled in freeradius code.
FreeRADIUS just calls: ldap_set_option( NULL, LDAP_OPT_X_TLS_CACERTFILE, ...) ...and similar in rlm_ldap.c:ldap_connect Interestingly, the 1st argument is NULL, not the LDAP* instance which has been created higher up, meaning those options are being (re)set globally, not per-connection. I wonder if that's the problem? You could try: perl -pe 's/(ldap[_a-z0-9]+)\(\s*NULL,/\1(ld,/g' src/modules/rlm_ldap/rlm_ldap.c ...which will change the above to: ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE, ...) i.e. they'll be set on the connection created, not globally.
Hi all is there anybody can tell me why my mikrotik ppp user sometimes authenticate fail on free radius? how to fix it? after few mins it will be oke...
On 05/04/2011 08:46 PM, Tanjil Ahmed wrote:
Hi all
is there anybody can tell me why my mikrotik ppp user sometimes authenticate fail on free radius?
Please don't hijack an existing thread. Start a new one.
how to fix it?
after few mins it will be oke...
You need to give us more information. See the FAQ for "it still doesn't work"
participants (4)
-
Alexander Clouter -
Daniele Albrizio -
Phil Mayers -
Tanjil Ahmed