We're Hiring!

OMERO 5.1.3 omero.security.ignore_case

Having a problem deploying OMERO? Please ask new questions at https://forum.image.sc/tags/omero
Please note:
Historical discussions about OMERO. Please look for and ask new questions at https://forum.image.sc/tags/omero

The OMERO.server installation documentation begins here and you can find OMERO.web deployment documentation here.

Re: OMERO 5.1.3 omero.security.ignore_case

Postby jbyars » Mon Aug 17, 2015 6:19 pm

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?
jbyars
 
Posts: 24
Joined: Wed Jun 01, 2011 9:51 pm

Re: OMERO 5.1.3 omero.security.ignore_case

Postby atarkowska » Tue Aug 18, 2015 10:51 am

Hi,

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

atarkowska wrote: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
atarkowska
 
Posts: 327
Joined: Mon May 18, 2009 12:44 pm

Re: OMERO 5.1.3 omero.security.ignore_case

Postby jbyars » Tue Aug 18, 2015 9:08 pm

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!
jbyars
 
Posts: 24
Joined: Wed Jun 01, 2011 9:51 pm

Re: OMERO 5.1.3 omero.security.ignore_case

Postby atarkowska » Wed Aug 19, 2015 8:16 am

Hi,

jbyars wrote:
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?

jbyars wrote: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
atarkowska
 
Posts: 327
Joined: Mon May 18, 2009 12:44 pm

Re: OMERO 5.1.3 omero.security.ignore_case

Postby jbyars » Wed Aug 19, 2015 9:23 pm

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.
jbyars
 
Posts: 24
Joined: Wed Jun 01, 2011 9:51 pm

Re: OMERO 5.1.3 omero.security.ignore_case

Postby atarkowska » Thu Aug 20, 2015 3:27 pm

Hi,

jbyars wrote: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)"



jbyars wrote: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).

jbyars wrote: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
atarkowska
 
Posts: 327
Joined: Mon May 18, 2009 12:44 pm

Re: OMERO 5.1.3 omero.security.ignore_case

Postby jbyars » Thu Aug 20, 2015 7:09 pm

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?
jbyars
 
Posts: 24
Joined: Wed Jun 01, 2011 9:51 pm

Re: OMERO 5.1.3 omero.security.ignore_case

Postby jmoore » Mon Aug 24, 2015 7:57 pm

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.
User avatar
jmoore
Site Admin
 
Posts: 1591
Joined: Fri May 22, 2009 1:29 pm
Location: Germany

Previous

Return to Installation and Deployment

Who is online

Users browsing this forum: No registered users and 1 guest