Can't log in to xnat after update to 1.8.6 | Bad credentials

222 views
Skip to first unread message

Birendra Rokaha

unread,
Oct 20, 2022, 9:10:53 PM10/20/22
to xnat_discussion
Hi,

We have a XNAT running on docker that we just updated from 1.8.5 to 1.8.6 and none of the users are able to log in. I've looked into the access logs and issue is "Bad credentials" but there had been no changes to the passwords. We used the same procedure to update the xnat as we did for earlier versions. 

2022-10-21 00:23:12,819 - admin 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" FAILED (LockedException): User account is locked: admin

2022-10-21 00:23:26,194 - admin 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" FAILED (LockedException): User account is locked: admin

2022-10-21 00:23:31,767 - admin 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" FAILED (LockedException): User account is locked: admin

2022-10-21 00:33:34,087 - userc 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Safari/605.1.15" FAILED (BadCredentialsException): Bad credentials

2022-10-21 00:37:24,987 - userb 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" FAILED (LockedException): User account is locked: userb

2022-10-21 00:45:05,263 - usera 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" FAILED (BadCredentialsException): Bad credentials

2022-10-21 00:45:35,833 - usera 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" FAILED (BadCredentialsException): Bad credentials

2022-10-21 00:52:33,459 - usera 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" FAILED (BadCredentialsException): Bad credentials

2022-10-21 00:54:13,416 - usera 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" FAILED (BadCredentialsException): Bad credentials

2022-10-21 00:59:09,847 - userb 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" FAILED (LockedException): User account is locked: userb

2022-10-21 01:06:45,616 - testuser 172.18.0.1 POST Authentication "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" FAILED (BadCredentialsException): Bad credentials

Any help would be appreciated.

Thanks,
Biren

Rick Herrick

unread,
Oct 21, 2022, 2:54:25 PM10/21/22
to xnat_di...@googlegroups.com
Hi Birendra,

In 1.8.6, we upgraded the encryption hashing for storing user passwords, but there is a migration process that happens partly on start-up and then on each user’s first successful login after upgrade. I’m guessing something went awry with that process in your XNAT deployment.

To set a baseline, I started XNAT 1.8.5 on a clean new database, created a bunch of users, then verified that all of them could log in. I then upgraded to 1.8.6, started back, verified the start-up migration, then verified that all of the users could log in. That all worked for me locally, so there must be something going on that’s different in your deployment. So questions:
  1. Do you have any plugins installed? A list of any plugins and their versions would be helpful.
  2. When you try to log into the server, do any messages show up anywhere besides the access log?
  3. Do you have any external authentication providers configured, e.g. LDAP, OpenID, etc.?
As a workaround for this, try going through the password reset process. I don’t want all of your users to have to do that but if you need to get admin access or something like that this should at least get you access to your XNAT.

Also, your users are locked out because of the failed authentication attempts (these are the LockedException entries in access.log). These locks will be cleared automatically after whatever the configured period of time is (by default, this is set to one hour), but you can clear them manually if you have access to the database with this query:

UPDATE xhbm_xdat_user_auth SET lockout_time = null;

Which is actually another question: do you have direct access to your database and, if so, do you know how to access it with psql or another tool?

If not, let me know how your database is deployed (I know your XNAT is deployed via Docker but are you using the XNAT Docker Compose project with the database also in Docker).

Rick Herrick
Senior Software Developer


------ Original Message ------
From "Birendra Rokaha" <birend...@gmail.com>
To "xnat_discussion" <xnat_di...@googlegroups.com>
Date 10/20/2022 8:10:53 PM
Subject [XNAT Discussion] Can't log in to xnat after update to 1.8.6 | Bad credentials

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/63181805-df4b-44a2-86fc-60bd664a1091n%40googlegroups.com.

Birendra Rokaha

unread,
Oct 22, 2022, 6:05:05 AM10/22/22
to xnat_discussion
Hi Rick,

Thanks a lot for getting back to me. I really appreciate it.
There was something fishy as it took about 2 hrs for the application to deploy after we upgraded to 1.8.6.
  1. Do you have any plugins installed? A list of any plugins and their versions would be helpful.
  1. I thought that might be the case and have tried to deploy with no plugins. It did not help. The plugins currently present are CS 3.3.0 and OHIF 3.3.0
  1. When you try to log into the server, do any messages show up anywhere besides the access log?
  1. I just get the standard username/password wrong or user logged out message. When i try to reset the user, I get "XNAT has encountered an error with your request error". All the error status are unknown.   
  1. Do you have any external authentication providers configured, e.g. LDAP, OpenID, etc.?
  1. There are no external auth providers
I have already gone with this process as well.  "UPDATE xhbm_xdat_user_auth SET lockout_time = null;" but after the users are unlocked they get bad credentials error again.
I have full access to the backend and I use psql to access the database. 
Is there a way we can reset the user password from the database itself or create an account with admin access from the backend?

Thanks a bunch,
Biren

Rick Herrick

unread,
Oct 24, 2022, 3:49:17 PM10/24/22
to xnat_di...@googlegroups.com
When you say “try to reset the user”, do you mean through the forgot password workflow? Presuming yes, do any errors appear in the XNAT logs when you get that error? Even if the password value in the database was completely messed up/corrupted you should be able to go through that workflow.

And I’m not sure why upgrading to 1.8.6 should cause take two

Have a look at the password columns in the table xdat_user. What I’m curious about is whether something bad happened to the password columns during migration. Try running this query:

SELECT (SELECT count(*) FROM xdat_user) AS user_count,
       (SELECT count(*) FROM xdat_user WHERE primary_password ~ '^[A-Fa-f0-9]{64}$' AND salt ~ '^[A-Za-z0-9]{64}$') AS sha256_2cols_count,
       (SELECT count(*) FROM xdat_user WHERE primary_password ~ '^[A-Fa-f0-9]{64}\{[A-Za-z0-9]{64}}$') AS sha256_1col_count,
       (SELECT count(*) FROM xdat_user WHERE primary_password ~ '^\{bcrypt\}\$2a\$10\$.*$') AS bcrypt_count;

The numbers generated here tell us how many of those rows:
  • Are in the user table (i.e. total number of users on the system)
  • Have their password and salt in a pre-1.8.6 format (64-character hexadecimal password hash in one column and 64-character salt in another)
  • Have their password and salt migrated to an interim format for migration (same password hash and salt as above, but in the form hash{salt})
  • Have their password encoding converted to use Bcrypt with a generated integrated salt value
If you don’t have any external authentication providers, these numbers should something like this immediately upon upgrade:
  • A non-zero number for the first column: as mentioned previously, this is just the total number of rows in the user table
  • 0 for the second column: on successful start-up immediately after upgrade, any row that matches this pattern should be converted and so no longer match
  • The same number as the first column for the third column: on successful start-up immediately after upgrade, any row that matches the previous pattern should be converted and now match this pattern
  • 0 for the fourth column: every user that successfully authenticates through the UI should decrease the number in the third column and increase the number in this column
Let me know what you find for log entries on the password reset operation and the results of this query.


Rick Herrick
Senior Software Developer


------ Original Message ------
From "Birendra Rokaha" <birend...@gmail.com>
To "xnat_discussion" <xnat_di...@googlegroups.com>
Date 10/22/2022 5:05:05 AM
Subject Re: [XNAT Discussion] Can't log in to xnat after update to 1.8.6 | Bad credentials

Reply all
Reply to author
Forward
0 new messages