Open Microscopy Environment

I've update a 4.4.9 linux install to 5.1.3 Windows and switched it to a different ldap server. Everything appeared to be working fine. Then I tried out the ignore_case option. I didn't catch that it was generating new lowercase accounts at first, until testing with a user and realizing she was effectively working from a new account (no images). So I shut down the server, turned ignore_case off, and restored a previous db backup to eliminate the duplicate account.
When we tested again I can log in and she could not. Looking in the blitz log there were exceptions thrown when she tries to log in. So, I shut down the server, turned_ignore case back on, went into the experimenter table, and changed all the usernames to lower case. It works great for me and another admin, but it still throws errors when the user tries to login. Strangely, my account was mixed case and after renaming accounts I didn't have any problems.
I've tried attaching an excerpt from the blitz log to show the errors, but I get "The extension is not allowed." no matter what I try. Any ideas how to fix this? Is there something else that needs to be purged? Who can I forward the log excerpt to? Thanks!

Hi

Can you zip up your logs and upload them to https://www.openmicroscopy.org/qa2/qa/upload/

Could you also give us the output of:

Code: Select all

omero config get --hide-password
omero admin diagnostics


Thanks, Simon

Logs uploaded and requested output uploaded. If it's too ugly, I can roll back to a previous image of the server and redo the upgrade again. Thanks for the help!

Hi,

Thank you for sending logs and config. Thank you for reporting your issue. We filed similar problem in https://trac.openmicroscopy.org/ome/ticket/12887

From the log file I can see that after 3rd restart users: jbyars and rgrattan were able to log in. Then as I understood you rolled back omero.security.ignore_case to false as I could see JByars logged in, but RGrattan couldn't

Code: Select all

2015-08-12 15:58:21,287 WARN  [        ome.services.util.ServiceHandler] (l.Server-9) Unknown exception thrown.

org.springframework.jdbc.UncategorizedSQLException: PreparedStatementCallback; uncategorized SQLException for SQL [select ome_nextval(?,?)]; SQL state [25P02]; error code [0]; ERROR: current transaction is aborted, commands ignored until end of transaction block; nested exception is org.postgresql.util.PSQLException: ERROR: current transaction is aborted, commands ignored until end of transaction block

Then RGrattan eventual managed to log in using Insight

Code: Select all

2015-08-12 16:16:31,869 INFO  [        ome.services.util.ServiceHandler] (.Server-17)  Executor.doWork -- ome.services.sessions.SessionManagerImpl.executeCheckPasswordRO[RGagnon]
2015-08-12 16:16:31,869 INFO  [        ome.services.util.ServiceHandler] (.Server-17)  Args:   [null, InternalSF@113760534]
2015-08-12 16:16:31,869 INFO  [         ome.security.basic.EventHandler] (.Server-17)  Auth:   user=0,group=0,event=null(Sessions),sess=8d3a4d1b-1dae-4508-88c8-3ac24f059052
2015-08-12 16:16:31,978 INFO  [                      ome.logic.LdapImpl] (.Server-17) Adding groups for RGagnon: [153, 504, 505, 506, 507, 603, 405, 553]
...
2015-08-12 16:16:32,103 INFO  [ ome.services.blitz.fire.SessionManagerI] (.Server-14) Created session ServiceFactoryI(session-eb14b51b-fde7-49d7-aaaa-a0eea7e4cc71/0a07d88a-7b4e-4719-a574-3e30e045d29a) for user RGagnon (agent=OMERO.insight)

After yet another restart I can see that she still managed to log in:

[code]2015-08-12 16:23:46,550 INFO  [        ome.services.util.ServiceHandler] (l.Server-1)  Executor.doWork -- ome.services.sessions.SessionManagerImpl.executeCheckPasswordRO[rgagnon]
2015-08-12 16:23:46,550 INFO  [        ome.services.util.ServiceHandler] (l.Server-1)  Args:   [null, InternalSF@987403938]
2015-08-12 16:23:46,550 INFO  [         ome.security.basic.EventHandler] (l.Server-1)  Auth:   user=0,group=0,event=null(Sessions),sess=516ff18f-40c1-4585-af3e-6547a0f45129
2015-08-12 16:23:46,769 INFO  [                      ome.logic.LdapImpl] (l.Server-1) Adding groups for rgagnon: [153, 504, 505, 506, 507, 603, 405, 553]
...
2015-08-12 16:23:46,894 INFO  [ ome.services.blitz.fire.SessionManagerI] (l.Server-4) Created session ServiceFactoryI(session-2195408d-fadb-495c-a9e1-3f4046ad3601/a8956cbf-3402-46db-8ddf-905911f6648f) for user rgagnon (agent=OMERO.insight)[/code]

[code]2015-08-12 16:25:01,964 INFO  [ ome.services.blitz.fire.SessionManagerI] (l.Server-1) Created session ServiceFactoryI(session-df900df9-7e19-4259-bcc4-7f5a7a7615c4/82ac71e4-5a14-42ec-b097-78029b6e9ac0) for user jbyars (agent=OMERO.insight)[/code]

As that is lowecase username I understand that at this point you lowered usernames and set omero.security.ignore_case=true?

As there were no server restart between 16:25:01 and 16:29:10 did she try to log in later? It looks like is random as I can see again SQLException.

[code]2015-08-12 16:29:10,349 INFO  [        ome.services.util.ServiceHandler] (l.Server-5)  Executor.doWork -- ome.services.sessions.SessionManagerImpl.executeCheckPasswordRO[rgrattan]
...
2015-08-12 16:29:10,505 WARN  [        ome.services.util.ServiceHandler] (l.Server-5) Unknown exception thrown.

org.springframework.jdbc.UncategorizedSQLException: PreparedStatementCallback; uncategorized SQLException for SQL [select ome_nextval(?,?)]; SQL state [25P02]; error code [0]; ERROR: current transaction is aborted, commands ignored until end of transaction block; nested exception is org.postgresql.util.PSQLException: ERROR: current transaction is aborted, commands ignored until end of transaction block


Please let me know if I missed anything above. We will investigate that issue deeply and let you know. In the meantime I think you need to continue with case sensitive usernames.

Sorry about that

Ola

There is one detail that was missed. RGrattan was only successful logging in when Omero generated a new account for her. So let me cover the scenarios really quick
Scenario 1: system updated, usernames not changed to lower case in Experimenter table, ignore_cases=true
RGrattan and JByars can log in, but we are logging into newly generated accounts. Not what we wanted.

Scenario 2: system updated, database rolled back, usernames not changed to lower case, ignore_cases=false
JByars can log into the right account, RGrattan gets an error.

Scenario 3: system updated, usernames changed to lower case in Experimenter table, ignore_cases=false
JByars or jbyars logs into the right account, RGrattan or rgrattan gets an error.

RGrattan cannot log in. I will of course verify the problem still exists this morning.

Hi

Could you send us the output of

Code: Select all

omero user list


Thanks, Simon

Results uploaded. I have verified RGrattan still cannot log in this morning. As you can see I changed the duplicate JByars account username to gibbersh and I can log in just fine. What is the proper way to delete a user account if they haven't created images or effectively done anything other than log in once?

Hi,

From the user table looks like there are 2 accounts grattan and grattangal where second is not an ldap user. Could I check that is correct and appropriate passwords were used to log in?

Code: Select all

id  | login      | first name | last name | email | active | ldap  | admin | member of |
----+------------+------------+-----------+-------+--------+-------+-------+-----------+-
52  | grattangal | R....      | G....     | rg..  | Yes    | False |       | 53        |


As of 5.1 OMERO no longer stores DN in a DB. If you need to convert any of the accounts to be discoverable by ldap try https://www.openmicroscopy.org/site/sup ... entication

Could you also add to the QA feedback 11359 you have created before (just click on the link in your email confirmation) an output of the

Code: Select all

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

replace {ldap user DN} and {BASE}

I am wondering if she actually match your omero.ldap.user_filter

Ola

She did successfully authenticate in scenario 1 mentioned above, so she does match the ldap.user_filter somehow. But, OMERO generated her a new account because RGrattan does not equal rgrattan. grattangal was an old local test account for her, when were were working out the original ldap settings a long time ago. I actually corrected the DN's while tested out 5.0.6, however I think you are on to something!

When I check her DN now, it's different from what I had on file. It doesn't match the results from

Code: Select all

omero ldap list

How do I change the DN entry for her account? Before I could just correct the passwords table if something went wrong.

Hi,

atarkowska wrote:As of 5.1 OMERO no longer stores DN in a DB (password table).

Code: Select all

$ dist/bin/omero ldap list

lookups directly in LDAP for all users where ldap flag = True.

Code: Select all

bin/omero ldap getdn --user-name USERNAME

checks particular user. They should return you the same value.

If listed DNs doesn't match your filter user won't be able to log in.

Ola