Open Microscopy Environment

The server is OMERO 4.3.4 running on Ubuntu 11.04. Everything is working fine for normal accounts. But, we cannot seem to get the system to make queries against the ldap provider. It does not show up in the provider's logs or in the Wireshark trace. The provider does require TLS/SSL. Ldap queries work fine from the command line using ldapsearch. We have imported the same cert into the keystore we used for the ldap.conf setup. Here is a sanitized excerpt from the config:

Code: Select all

omero.data.dir=/data/OMERO.data/
omero.db.host=localhost

omero.security.filter.bitand=(int8and(permissions,%s) = %s)
omero.security.password_provider=chainedPasswordProvider
omero.security.login_failure_throttle_count=1
omero.security.login_failure_throttle_time=3000
omero.security.keyStore=/data/apps/OMERO/.keyStore
omero.security.keyStorePassword=********
omero.security.trustStore=/data/apps/OMERO/.keyStore
omero.security.trustStorePassword=********

############################################
# Ldap properties
############################################
omero.ldap.config=true
omero.ldap.urls=ldaps://foo.whatsamatterwithu.edu:389
omero.ldap.username=cn=omeroldap,ou=ldap,ou=misc,o=hsc
omero.ldap.password=********
omero.ldap.base=o=hsc

omero.ldap.sync_on_login=true

omero.ldap.user_filter=(objectClass=User)
omero.ldap.user_mapping=omeName=cn,firstName=givenName,lastName=sn,email=mail

omero.ldap.group_filter=(objectClass=groupOfNames)
omero.ldap.group_mapping=name=cn

omero.ldap.new_user_group=OmeroTestgrp

First assuming the provider requires ssl and operates on port 389 is the correct setting

omero.ldap.urls=ldaps://server:389

? I've tried every permutation I can think of. Second would someone be able to provide me a little guidance on what I'm looking for in the Blitz-0.log to make sense of this? Thanks.

Code: Select all

omero.ldap.urls=ldaps://foo.whatsamatterwithu.edu:389
omero.ldap.username=cn=omeroldap,ou=ldap,ou=misc,o=hsc
omero.ldap.password=********
omero.ldap.base=o=hsc
omero.ldap.sync_on_login=true
omero.ldap.user_filter=(objectClass=User)
omero.ldap.user_mapping=omeName=cn,firstName=givenName,lastName=sn,email=mail
omero.ldap.group_filter=(objectClass=groupOfNames)
omero.ldap.group_mapping=name=cn
omero.ldap.new_user_group=OmeroTestgrp

Assuming these are the same values you see when you run

Code: Select all

bin/omero config get


they seem quite reasonable. My first guess would be that something's not working with the keystore.

Second would someone be able to provide me a little guidance on what I'm looking for in the Blitz-0.log to make sense of this? Thanks.

Typically, I'd start by "grep -i" ing for ldap in the Blitz-0.log file. If you can't find anything, you attach Blitz-0.log along with master.out and master.err here.

~Josh

Sorry, I didn't get to this last week. This is all I get when I try to dump the config:

Code: Select all

omero@hsc-omero:/data/apps/OMERO/OMERO.server$ bin/omero config get
omero.data.dir=/data/OMERO.data
omero.db.name=omerodb
omero.db.pass=****
omero.db.user=omerouser
omero.security.keyStore=.keyStore
omero.security.keyStorePassword=****
omero.security.trustStore=.keyStore
omero.security.trustStorePassword=****
omero.web.application_host=http://foo.edu:80
omero.web.application_server=fastcgi-tcp
omero.web.server_email=jbyars@foo.edu


Strangely the path for the keystore file isn't shown. Also, nothing ldap is reported. I tried commenting out a few lines of omero.properties to see if there was an obvious typo and it didn't help. If I use keytool to list the keystore, it works and lists the certificate. Is there something else I can do to test it? What does it mean if this is all of the keys listed?

Right I had a senile moment and I was editing in omero.properties on this setup and not doing the settings with omero config set. So I went back and set all the properties using omero config. Now I have more ldap messages in Blitz-0.log than I know what to do with. At the moment the problem seems to stem from simple bind failed.
The next problem is if I use ldaps for the ldap.urls, I get

[Root exception is javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?]

But, if I just use ldap.urls=ldap://foo.edu:389, I get this

2012-05-21 16:41:44,411 INFO [ ome.services.util.ServiceHandler] (l.Server-0) Excp: java.lang.NullPointerException
2012-05-21 16:41:44,411 ERROR [services.blitz.fire.PermissionsVerifierI] (l.Server-0) Exception thrown while checking password for:me
ome.conditions.InternalException: Wrapped Exception: (java.lang.NullPointerException):
null

Any ideas? for a TLS provider, will it negotiate a session as long as the keyStore is available? Thanks!

I don't think it will TLS up to a secure connection when setting the URL to ldaps:...:389/ you can try using the correct port for secure LDAP communication which is TCP/636.

Actually I can't. The ldap server appears to be configured for TLS on port 389 only. Port 636 gets no response. It appears it is negotiating TLS ok. My problem now is failing to get a DistingushedName for the password authentication. Is there any debug option I can set so I can see the ldap queries in the logs? Thanks

Confirmed ldaps://provider:389 does negiotate TLS correctly. The problem is the username capitalization in the ldap tree differs from what most people normally authenticate with, which creates a DistinguishedName error in the logs. I would love to see this behavior handled in 4.4. Should I submit this as an additional request or should this be part of task #8936? Thanks

jbyars wrote:Confirmed ldaps://provider:389 does negiotate TLS correctly.

Interesting. Good to know, thanks.

The problem is the username capitalization in the ldap tree differs from what most people normally authenticate with, which creates a DistinguishedName error in the logs.

Can you give an example of the different capitalizations that you tried? There's a separate ticket for case-sensitivity issues, but I'm not completely sure it's related.

Should I submit this as an additional request or should this be part of task #8936? Thanks

Adding information to 8936 should be fine, though it'll also be found here in this thread.

~Josh

Say my name is Darth Vader. Most of the time the username, i.e. cn generated in ldap would be DVader. Now 90+% of the systems around here will authenticate successfully if I use dvader instead. So 90+% of the users around here have no idea what their correct cn is. Of course there are some non conforming cn's in the mix as well to keep things interesting. If I log in as dvader instead of DVader, Omero logs a DistinguishedName error in the Blitz-0.log and fails to log in but finds 1 record. Would you like me to send a copy of the log? The fix doesn't necessarily have to succeed authenticating a cn with mismatching capitalization. But, it would be nice if the login error message would complain about capitalization and the Blitz-0.log error would point out what is happening. Thanks

That does sound like the case-(in)sensitivity issue: See https://trac.openmicroscopy.org.uk/ome/ticket/4821

Thanks,
~Josh