Open GoogleCodeExporter opened 9 years ago
Oops, I forgot to add that the second set of output is for when I use LDAPS
Original comment by ugo...@gmail.com
on 16 May 2012 at 11:36
Thu Aug 22 17:11:29 BST 2013
Also having the same problem. Using ldapsearch, can connect using ldaps://...
Does the plugin work with an ldaps URI?
Original comment by rpri...@gmail.com
on 22 Aug 2013 at 4:20
I'm experiencing the same issue. It looks like it can't create a connection with ldaps is specified. I get a LDAP connect failed.
Same issue here. Were you able to resolve the issue?
While I wasn't able to make the ldap query use ldaps, the issue of transferring unencrypted ldap data over the network can be resolved with a little workaround:
Using autossh and upstart I created a ssh tunnel to the ldap port of the ldap server that is created automatically on startup of the server providing openvpn. The auth-ldap plugin can then be configured to query on localhost, the query itself is issued (and encrypted) over ssh.
While the setup is a bit more complicated than replacing "ldap" with "ldaps", it works quite well.
Shouldn't TLSEnable yes
be TLSEnable no
when using ldaps://
protocol? LDAPS uses plain SSL on port 636, while StartTLS ist used with ldap://
protocol on port 389, where the connection is opened unencrypted and then negotiates it over TLS with the server.
'TLSEnable yes' is supposed to enable STARTTLS, so you connect first on port 389 and start TLS second. Using the Debian 2.0.3 distro package this works fine. Using the Amazon Linux 2.0.3 distro package this setting seems to get entirely ignored, it connects on port 389 and just never tries to STARTTLS. There is no error or other message in the openvpn logs from the plug-in. Binding fails because TLS hasn't been started. The 'TLSEnable yes' setting is in the example config so you would think it was also in the code?
Removing the TLSEnable and using and 'ldaps://' instead works fine as a workaround, but STARTTLS would be better if it worked.
Was anybody able to make it work?
My setup:
I have my own CA that issued certificate for AD server (keysize 4096, sha512)
I tried: URL ldaps://ads1.ad.example.com (translation to IP in /etc/hosts) TLSEnable yes/no (both options tested) TLSCACertFile /etc/openvpn/certs/ca.crt (the certificate of my CA)
I temporarily switched SELinux to permissive mode.
I got: LDAP bind failed immediately: Can't contact LDAP server (error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate))
I can see in WireShark, that OpenVPN server sends fatal TLS error Unknown CA. It seems that TLSCACertFile file option is ignored.
When I use openssl s_client with -CAfile options, it properly verifies AD server's certificate and connects to it.
My workaround on #65 may help
DId anyone get this working with ldaps? I would appreciate even a hint on why it doesn't work as the openvpn guys say they support ldaps. I exported a CA file fro the AD Server to the OpenVPN Server and I could connect using openssl s_client just fine. I get the error here below. I can connect with ldap just fine using the same credentials but not ldaps.
LDAP bind failed immediately: Can't contact LDAP server Unable to bind as openvpnquery@domain.net LDAP connect failed. PLUGIN_CALL: POST /usr/local/lib/openvpn-auth-ldap.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/local/lib/openvpn-auth-ldap.so TLS Auth Error: Auth Username/Password verification failed for peer
@softwareinfojam I am not sure if you have the same problem as myself but I end up fixing it with this: https://github.com/threerings/openvpn-auth-ldap/issues/65#issuecomment-430456798
I was able to work around this by adding the CA cert to the system truststore (which I believe shows that the issue is that the TLSCACertFile setting is effectively ignored).
More details here: https://github.com/threerings/openvpn-auth-ldap/issues/65#issuecomment-829383257
Original issue reported on code.google.com by
ugo...@gmail.com
on 16 May 2012 at 10:26