Open Microscopy Environment

I'm having trouble getting our Omero server (omero 4.3.3 on CentOS 5.7) to bind to LDAP - It looks like the omero ldap plugin is crashing? Our LDAP server is a windows domain controller. Attempting to log in via the web client with AD credentials yields:

Error: Connection not available, please check your user name and password

The relevant Blitz-0.log entries:

2011-12-02 10:01:24,874 INFO [ ome.services.util.ServiceHandler] (l.Server-8) Excp: org.springframework.ldap.PartialResultException: Unprocessed Continuation Reference(s); nested exception is javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ''
ome.conditions.InternalException: Wrapped Exception: (org.springframework.ldap.PartialResultException):
at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:203)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:315)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:259)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:606)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:524)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:473)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:493)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:513)

omero config:

[omerouser@omero3 OMERO.server-Beta-4.3.3]$ bin/omero config get
omero.data.dir=/OMERO1
omero.db.host=****.jax.org
omero.db.name=omero1
omero.db.pass=*****
omero.db.user=omero
omero.ldap.base=dc=jax,dc=org
omero.ldap.config=true
omero.ldap.password=***************
omero.ldap.urls=ldap://********.jax.org:389
omero.ldap.username=cn=**********,ou=***,ou=*********,ou=**********,DC=jax,DC=org
omero.web.application_host=http://omero3.jax.org:80/
omero.web.application_server=fastcgi-tcp
omero.web.email_host=****.jax.org
omero.web.server_email=***@jax.org
omero.web.server_list=[["omero3.jax.org", 4064, "omero1"], ["omero3.jax.org", 24064, "omero2"]]


Any help is appreciated...

Hi,

unfortunately we have little to no experience testing the LDAP plugin with AD, so we will need your help tracking down the best fix. Searching for the exception I found this fairly precise Jira KB entry:

• https://confluence.atlassian.com/display/JIRAKB/User+Lookups+Fail+With+%27PartialResultExceptions%27+Due+to+Active+Directory+%27follow+referrals%27+Configuration

Do you know how necessary the use of referrals are in your AD setup? Would it be acceptable to disable them globally? And finally, is there anyone who can look into the DNS entries for the AD servers? From what I've read, that may be the only full solution without modifying the code.

Cheers,
~Josh.

See also:

• http://www.mail-archive.com/cas@tp.its.yale.edu/msg00797.html
• https://jira.atlassian.com/browse/CWD-1096
• http://forum.springsource.org/showthread.php?87673-Referrals-and-Active-Directory

Thank you, I'll see what I can find out about our AD implementation.

So we've managed to get LDAP sort of working against AD, but with some issues:

1st, using our base dn as the ldap base didn't work; we had to specify an OU that contained users directly, seems like the plugin can't traverse nested groups/OUs?
2nd, we found that we must use the full canonical account name to log in, for example if my sam account username is user, the only way the ldap plugin would accept my username is User Name user, is there a way to allow log based on sam account only? ldapuser mapping perhaps?
3rd, it seems that when an ou is changed, the ldap plugin will create a new user record in omero for the user account. Is there a way around that behavior, or at least a way to consolidate user accounts after the fact?

Thanks for any info or advice...

rb-mdi wrote:1st, using our base dn as the ldap base didn't work; we had to specify an OU that contained users directly, seems like the plugin can't traverse nested groups/OUs?

Is this due to the referals? What exception were you getting?

2nd, we found that we must use the full canonical account name to log in, for example if my sam account username is user, the only way the ldap plugin would accept my username is User Name user, is there a way to allow log based on sam account only? ldapuser mapping perhaps?

Can you show me an example of an LDAP user entry? You certainly shouldn't need to use "User Name" as your login. You aren't currently using a omero.ldap.user_mapping setting, correct?

3rd, it seems that when an ou is changed, the ldap plugin will create a new user record in omero for the user account. Is there a way around that behavior, or at least a way to consolidate user accounts after the fact?

This may be related to your 2nd issue, so we may want to solve that first. You can certainly modify both the user's "omeName" as well as the DN which is set, but these much match the rest of your LDAP configuration.

Cheers,
~Josh

P.S. feel free to send LDAP examples and configuration via private message if you'd prefer.

I don't believe the reference issue is affecting us; our DCs are configured in DNS and AD with the same fqdn they use locally... but let me know if I'm misunderstanding that issue. Only issue so far I believe is the base problem. Still unable to set the base as jax.org so that it will grab all the users from the different sub ou’s.
Here is the exception when using the jax.org base.

2011-12-07 09:47:41,610 INFO [ ome.services.util.ServiceHandler] (l.Server-8) Excp: org.springframework.ldap.PartialResultException: Unprocessed Continuation
Reference(s); nested exception is javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ''
2011-12-07 09:47:41,611 ERROR [services.blitz.fire.PermissionsVerifierI] (l.Server-8) Exception thrown while checking password for:####
ome.conditions.InternalException: Wrapped Exception: (org.springframework.ldap.PartialResultException):
Unprocessed Continuation Reference(s); nested exception is javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ''

An example ldap user entry: cn="John Doe (Admin)", ou=BH,ou=AdminAccounts,ou=Bar_Harbor,DC=jax,DC=org

This is all coming down to LDAP referrals and how early they are happening in your directory hierarchy. It's going to take some investigation and testing to get this right and to make sure that changes in the base configuration don't break other LDAP/AD configurations. A ticket has been created (http://trac.openmicroscopy.org.uk/ome/ticket/7391) where we'll try and handle this and you'd been CC'd. How comfortable would you be with building the server from source?

Just in case it might be useful for anyone, we have authentication with our ActiveDirectory by using just the "short" account name as user name for OMERO.

The corresponding setting for the user mapping we're using here is this one:

Code: Select all

omero.ldap.user_mapping=omeName=sAMAccountName,firstName=givenName,lastName=sn,email=mail

For the bind DN we have a username of the form

Code: Select all

ldapreadonly@ads.domain.whatsoever

With this settings, users are able to log in with just their username without having to specify a domain name suffix (or prefix as it's handled on windows most of the time).

In case you're authenticating against multiple windows domains (a "forest"), the global catalog could be used instead of the single domain controllers. This global catalog usually is available on the domain controllers of the forest's root domain on the special port 3268 (instead of the default 389).

Feel free to ask for more details, I'll be happy to share my experience!

~Niko