Using LDAP with Start TLS on port 389

[Sethur]

Hi,

our LDAP server used by OMERO to authenticate users runs on the same machine, so up to now I was still fine with leaving the connection unencrypted, although our server support Start TLS on port 389. I'd prefer having an encrypted connection, though, and tried to set OMERO to use Start TLS, but it seems, that only ldaps via (standard port 636) is possible. Can you confirm this?

Regards,

Tristan

[jmoore]

Could you share your configuration (minus passwords) with us? Though I don't have such a set-up to try, I would suspect that ldaps://host:389 would do what you want. What error are you receiving? Is there anything in Blitz-0.log?

Cheers,
~Josh.

[Sethur]

Hi Josh,

the original config (before I tried to turn on SSL) looked like this:

Code: Select all

omero.data.dir=/srv/omero_data
omero.db.name=omerodb
omero.db.pass=xxx
omero.db.poolsize=50
omero.db.user=omero
omero.ldap.base=dc=oice
omero.ldap.config=true
omero.ldap.new_user_group=oice_private
omero.ldap.referral=ignore
omero.ldap.urls=ldap://localhost:389
omero.ldap.user_filter=(memberOf=cn=omerologins,ou=groups,dc=oice)
omero.ldap.user_mapping=omeName=uid,firstName=givenName,lastName=sn,email=mail
omero.sessions.timeout=3600000
omero.web.application_server=fastcgi-tcp
omero.web.debug=False


This worked fine. The problem is, that our server does not enforce to use TLS when connecting on port 389. As far as I could find out, OMERO is also not capable of doing a startTLS session, even when enforcing TLS on port 389. So I turned on ldaps (which uses another protocol forcing encryption form the start) on port 636 and changed the config to:

Code: Select all

omero.data.dir=/srv/omero_data
omero.db.name=omerodb
omero.db.pass=xxx
omero.db.poolsize=50
omero.db.user=omero
omero.ldap.base=dc=oice
omero.ldap.config=true
omero.ldap.new_user_group=oice_private
omero.ldap.referral=ignore
omero.ldap.urls=ldaps://our-server.de:636
omero.ldap.user_filter=(memberOf=cn=omerologins,ou=groups,dc=oice)
omero.ldap.user_mapping=omeName=uid,firstName=givenName,lastName=sn,email=mail
omero.security.trustStore=/home/omero/.ssl/truststore
omero.security.trustStorePassword=xxx
omero.sessions.timeout=3600000
omero.web.application_server=fastcgi-tcp
omero.web.debug=False


Now, I get the following error in Blitz-0.log when I try to log on as an LDAP user:

Code: Select all

org.springframework.ldap.CommunicationException: simple bind failed: romulus.oice.uni-erlangen.de:636; nested exception is javax.naming.CommunicationException: simple bind failed: romulus.oice.uni-erlangen.de:636 [Root exception is javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty]

I tried to create a java truststore containing the last certificate in the chain used by our certificate provider (the university), but this should technically not be necessary since the university uses a well-known root CA. Unfortunately, this led to the same error. I did not try to create a java keystore, since our server does not require client certificates.

Any ideas on how I can get a secure ldap authentication working?

Best,

Tristan

[bpindelski]

Hi Tristan,

After looking at the specific exception produced by the JRE, I would suggest the following:
1. Try setting "omero.security.keyStore" to point to the same file as "omero.security.trustStore" (see http://www.openmicroscopy.org/site/supp ... ruststores).
2. Verify that the "cacerts" supplied with your specific JRE/JDK installation contains the root CA that your university uses (in other words - verify that the running JVM can establish a chain of trust when authenticating your LDAP server).
3. If neither 1 nor 2 won't help, try removing the "trustStore" setting completely.

These are very general suggestions, but every LDAP deployment differs. Please let us know how you get on and post any relevant error messages so that the community can help further.

Regards,
Blazej

[Sethur]

As discussed with Kenny on the OME 2014 User Meeting, I'm posting the relevant Blitz-0.log line again:

Code: Select all

2014-06-06 09:55:36,742 INFO  [        ome.services.util.ServiceHandler] (l.Server-4)  Excp:    org.springframework.ldap.CommunicationException: simple bind failed: romulus.oice.uni-erlangen.de:636; nested exception is javax.naming.CommunicationException: simple bind failed: romulus.oice.uni-erlangen.de:636 [Root exception is javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty]
2014-06-06 09:55:36,744 ERROR [     o.s.blitz.fire.PermissionsVerifierI] (l.Server-4) Exception thrown while checking password for:ttester
ome.conditions.InternalException:  Wrapped Exception: (org.springframework.ldap.CommunicationException):
simple bind failed: romulus.oice.uni-erlangen.de:636; nested exception is javax.naming.CommunicationException: simple bind failed: romulus.oice.uni-erlangen.de:636 [Root exception is javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty]


I'm using the following Java version:

java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.13.10.1)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

[Sethur]

OK, Kenny just pointed out that I had the wrong path in

Code: Select all

omero.security.trustStore

which meant that the system could not find the truststore file. This was not really reflected in the error message (trust anchor can't be empty), so it might be good to put that in the documentation.

Another note: The keystore path does not need to be set for ldaps to work, if one is not using client side certificates.

[bpindelski]

Hi Tristan,

It was great to see you at the OME users meeting and thanks for the feedback. I've opened a PR that adds some explanation to our LDAP documentation: https://github.com/openmicroscopy/ome-d ... n/pull/814. I hope that will make it clearer how to handle non-OMERO error messages.

Regards,
Blazej