LDAPS auth against AD

[GoogleCodeExporter]

What steps will reproduce the problem?
1. If I try to run /testplugin /etc/openvpn/ldapconf/auth-ldap.conf, using the 
URL     ldap://192.168.3.25 config, it works
2. If i run it with URL     ldaps://192.168.3.25, it doesn't work

192.168.3.25 is a domain controller with ldap and ldaps ports open.  We have 
servers that authenticate against this host using ldaps.

What is the expected output? What do you see instead?
When using LDAP:
Authorization Succeed!
client-connect succeed!
client-disconnect succeed!

LDAP bind failed immediately: Can't contact LDAP server ((unknown error code))
Unable to bind as admin2@XXX.YYY
LDAP connect failed.
Authorization Failed!

What version of the product are you using? On what operating system?

I'm using auth-ldap-2.0.3 on Ubuntu 10.10 server

Please provide any additional information below.

#auth-ldap.conf 

<LDAP>
    # LDAP server URL
    URL     ldaps://192.168.3.25

    # Bind DN (If your LDAP server doesn't support anonymous binds)
    # BindDN        uid=Manager,ou=People,dc=example,dc=com
    BindDN          admin2@XXX.YYY

    # Bind Password
    # Password  SecretPassword
    Password    SomePassword    

    # Network timeout (in seconds)
    Timeout     15

    # Enable Start TLS
    TLSEnable   yes

    # Follow LDAP Referrals (anonymously)
    FollowReferrals yes

    # TLS CA Certificate File
    #TLSCACertFile  /usr/local/etc/ssl/ca.pem

    # TLS CA Certificate Directory
    #TLSCACertDir   /etc/ssl/certs

    # Client Certificate and key
    # If TLS client authentication is required
    #TLSCertFile    /usr/local/etc/ssl/client-cert.pem
    #TLSKeyFile /usr/local/etc/ssl/client-key.pem

    # Cipher Suite
    # The defaults are usually fine here
    # TLSCipherSuite    ALL:!ADH:@STRENGTH
</LDAP>

<Authorization>
    # Base DN
    BaseDN      OU=SBSUsers,OU=Users,OU=MyBusiness,DC=XXX,DC=YYY

    # User Search Filter
    SearchFilter    "(SAMAccountName=%u)"

    # Require Group Membership
    RequireGroup    false

Original issue reported on code.google.com by ugo...@gmail.com on 16 May 2012 at 10:26

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[ahromis]

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.

[gierdo]

Same issue here.
Were you able to resolve the issue?

[gierdo]

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.

[felixbuenemann]

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.

[whereisaaron]

'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.

[michalsladek]

Was anybody able to make it work?

My setup:

• Centos 7.5
• openvpn-2.4.6-1.el7.x86_64 (EPEL)
• openvpn-auth-ldap-2.0.3-15.el7.x86_64 (EPEL)

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.

[avs262]

My workaround on #65 may help

[softwareinfojam]

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

[sakoula]

@softwareinfojam I am not sure if you have the same problem as myself but I end up fixing it with this: #65 (comment)

[saulp]

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: #65 (comment)