OMERO 5.1.3 omero.security.ignore_case

[jbyars]

Yes, that is the idea. The DN did not match. If the response I get from

Code: Select all

bin/omero ldap getdn --user-name USERNAME

does not match the record in ldap, how do I correct the DN entry in OMERO?

[atarkowska]

Hi,

Could you send me the entry of the person that cannot log in as requested before

ldapsearch -x -LLL -H ldaps://your_ldap_host -D {ldap user DN} -W -b "{BASE}" -s sub "(cn=grattan)"

I will help you to alter omero ldap config.

Ola

[jbyars]

Code: Select all

ldapsearch -x -LLL -H ldaps://your_ldap_host -D {ldap user DN} -W -b "{BASE}" -s sub "(cn=grattan)"

doesn't work on an ADS ldap server. If you mean "(cn=*grattan)", the results have been uploaded. I made a mistake updating the DN field in the password table in 5.0.6. I just need to know how to correct it in 5.1.3. I was able to fix the user's account with a lame hack explained in the upload. If I could force the getdn results to refresh for all users, that would be perfect. Thanks!

[atarkowska]

Hi,

Code: Select all

ldapsearch -x -LLL -H ldaps://your_ldap_host -D {ldap user DN} -W -b "{BASE}" -s sub "(cn=grattan)"

doesn't work on an ADS ldap server.

How do you mean doesn't working? What error are you getting?

I made a mistake updating the DN field in the password table in 5.0.6. I just need to know how to correct it in 5.1.3. I was able to fix the user's account with a lame hack explained in the upload. If I could force the getdn results to refresh for all users, that would be perfect. Thanks!

You didn't make any mistake with updating DNs in 5.0.6. As of 5.1 series we removed DNs from database. That means you cannot update DN in omero anymore because is dynamically generated based on omero ldap config. OMERO no longer stores DNs. Could you provide us with an output of

Code: Select all

bin/omero ldap getdn --user-name grattan

and for comparison please copy her DN from the AD.

Ola

[jbyars]

If you do the ldapsearch you want, you get this response

Code: Select all

# extended LDIF
#
# LDAPv3
# base <ou=hsc,dc=health,dc=unm,dc=edu> with scope subtree
# filter: (cn=grattan)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1


If you do

Code: Select all

bin/omero ldap getdn --user-name grattan

You get back

Code: Select all

Created session 66d5ef63-191e-4bd7-a438-10f90482416b (root@localhost:4064). Idle
timeout: 10 min. Current group: system
Unknown user: grattan


The user's account is RGrattan. I did make a mistake updating the DN record for that user in 5.0.6. Now I agree with you, that shouldn't matter in 5.1.3 if the DN information refreshes dynamically. But, it does matter. What I was trying to show you in the attachment from yesterday (if you don't have it please let me know) is the response from

Code: Select all

bin/omero ldap getdn --user-name rgrattan

has changed. When I first updated the server to 5.1.3 her getdn response was the mistake DN from the 5.0.6 table carried forward. After changing the username of her account, letting a new account generate for her, and switching account user names back for the real account the getdn response changed to match her DN on the ADS ldap server.

For some reason any mistakes I made in the 5.0.6 carried forward. Whatever event that regenerates the results for getdn, did not happen. The user can now log into the correct account without getting an error. I'm sorry, but I'm not sure I can reproduce the error again without rolling back to a 5.0.6 snapshot of the system and repeating the upgrade.

[atarkowska]

Hi,

If you do the ldapsearch you want, you get this response

Code: Select all

# extended LDIF
#
# LDAPv3
# base <ou=hsc,dc=health,dc=unm,dc=edu> with scope subtree
# filter: (cn=grattan)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1


If grattan DN is cn=rgrattan,...,ou=hsc,dc=health,dc=unm,dc=edu
ldapsearch should find it. Are you sure you used an appropriate manager account to connect to AD (anonymous may not allow you to see the result)?

Code: Select all

ldapsearch -x -LLL -H ldaps://your_ldap_host -D "cn=manager,dc=example,dc=com" -W -b "ou=hsc,dc=health,dc=unm,dc=edu" -s sub "(cn=grattan)"

If you do

Code: Select all

bin/omero ldap getdn --user-name grattan

You get back

Code: Select all

Created session 66d5ef63-191e-4bd7-a438-10f90482416b (root@localhost:4064). Idle
timeout: 10 min. Current group: system
Unknown user: grattan


The user's account is RGrattan. I did make a mistake updating the DN record for that user in 5.0.6. Now I agree with you, that shouldn't matter in 5.1.3 if the DN information refreshes dynamically. But, it does matter. What I was trying to show you in the attachment from yesterday (if you don't have it please let me know) is the response from

Code: Select all

bin/omero ldap getdn --user-name rgrattan

has changed.

I got your ldapsearch.txt (sorry, please make sure you always put your email address when submitting the file, then we can identify it faster).

When I first updated the server to 5.1.3 her getdn response was the mistake DN from the 5.0.6 table carried forward. After changing the username of her account, letting a new account generate for her, and switching account user names back for the real account the getdn response changed to match her DN on the ADS ldap server.

For some reason any mistakes I made in the 5.0.6 carried forward. Whatever event that regenerates the results for getdn, did not happen. The user can now log into the correct account without getting an error. I'm sorry, but I'm not sure I can reproduce the error again without rolling back to a 5.0.6 snapshot of the system and repeating the upgrade.

That sound very strange. As of 5.1 you should be able to easily switch between LDAP/AD with just updating omero.ldap config.
If you wish to enable or disable an ldap authentication for particular account you can always use

Code: Select all

usage: bin/omero ldap setdn [-h] [--user-id USER_ID] [--user-name USER_NAME]
                            [--group-id GROUP_ID] [--group-name GROUP_NAME]
                            [-C] [-s SERVER] [-p PORT] [-g GROUP] [-u USER]
                            [-w PASSWORD] [-k KEY] [--sudo ADMINUSER] [-q]
                            choice

Enable LDAP login for user (admins only)

Once LDAP login is enabled for a user, the password set via OMERO is
ignored, and any attempt to change it will result in an error. When
you disable LDAP login, the previous password will be in effect, but if the
user never had a password, one will need to be set!

Positional Arguments:
  choice                            Enable/disable LDAP login (true/false)

bin/omero ldap setdn --user-name rgrattan


Perhaps was easier to do it rather then create new and rename. See doc https://www.openmicroscopy.org/site/sup ... entication

Code: Select all

bin/omero ldap getdn --user-name rgrattan

should always return appropriate DN.

Last thing you may want to check your operations and see if

Code: Select all

omero user list

indicates that LDAP flag is True and

Code: Select all

omero ldap list

returns appropriate DN for that user.

Sorry for a long response.
Ola

[jbyars]

When I use ldapsearch, I use an account specifically created for querying not anonymous. As long as I use wild cards or a cn that exists, it works fine. The account is quite restrictive though, so it is conceivable some queries aren't allowed. Sorry, I thought I put in an email address with the last upload.

The LDAP flag was set to True for rgrattan. I did try toggling it back and forth before doing the throw away account ritual. At this point I guess we just write the mismatched DN off as a fluke. If the ldap query that updates the entries for getdn was having problems, would it show up in any of the logs?

[jmoore]

Hi Jason,

sorry for coming to this thread late, but it certainly couldn't hurt to look at the server log if you could upload it. Beyond that, I'm inclined to agree that this may not be reproducible. Once your server was upgraded to 5.1, there was no DN for any user in the DB, but a combination of configuration settings & restarts could have left the user temporarily inaccessible. Regardless, I'm happy to read the logs and see if there's anything we can catch in the future. Sorry for your troubles.

~Josh.