Change account from database to LDAP authentication

[elijah....@gmail.com]

Hello, we have some user accounts that were created manually by an administrator. Unfortunately I realize now that creating them manually has automatically associated them with a database login authentication method.

However these were supposed to be LDAP accounts. And I see no way to change the associated authentication method via the XNAT web application.

Is there a way to link a currently existing "database" account with an LDAP account, or some way of changing the associated auth method?

[Moore, Charlie]

Hi Eli,

If it's acceptable for these accounts to have both LDAP and localdb auth, this is something I believe XNAT handles. When one of these users logs in with LDAP for the first time (at least on current XNAT builds), XNAT should prompt them if they want to create a new XNAT account or tie their LDAP login to an existing account. If they select the option to connect their LDAP credentials to an existing account, they should be able to log into the existing account in the future with LDAP (to make the association, they will also obviously need to provide the localdb account's password).

Thanks,

Charlie

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of elijah....@gmail.com <elijah....@gmail.com>
Sent: Thursday, July 1, 2021 12:55 PM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [XNAT Discussion] Change account from database to LDAP authentication

 

* External Email - Caution *

Hello, we have some user accounts that were created manually by an administrator. Unfortunately I realize now that creating them manually has automatically associated them with a database login authentication method.

However these were supposed to be LDAP accounts. And I see no way to change the associated authentication method via the XNAT web application.

Is there a way to link a currently existing "database" account with an LDAP account, or some way of changing the associated auth method?

--
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/a908715d-d7d4-433c-b4e7-1ac521af90a6n%40googlegroups.com.

 

---

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[elijah....@gmail.com]

Hi Charlie,

We are on 1.6.5, currently upgrading to 1.8. Our production server has a myriad of users that have duplicated usernames, some which are uppercase, some lower case, and some that even somehow ended up with _01 appended to the end (hilariously, if I try to change an email address belonging to one of the _01 duplicate accounts, I get an error message saying the underscore is an invalid character for a username, so I have no idea how it got there)

Anyway, I gather from previous threads here that this is an issue resulting from the LDAP vs. Database confusion that XNAT had, and they didn't play nice in the past (we are on 1.6.5). We have considered using javascript (or whatever) to force all entered usernames to be lowercase in the future to try to cut down on this. Is something like that viable, or even needed in 1.8?

Also, it's a bit tricky to sort out exactly how all these duplicate accounts got created, but going forward, for creating new users in 1.8, what is the preferred way to achieve this without ending up with twice as many unused duplicated accounts in the user table? And is there anything in particular (script, policy, plugin, etc) we should put in place to prevent this kind of annoyance in the future?

Also, I know XNAT doesn't support removing users for a variety of reasons, I'm just wondering if it would be technically possible to do without corrupting some other critical association in the database. Particularly in the context of upgrading from 1.6.5 to 1.8, and trying to clean up the user table a bit in the process.

Thanks,

-Eli

[elijah....@gmail.com]

This is still a very annoying problem. We have users who are unable to access XNAT because their "LDAP" login username is associated with a database account, and they have these other ghost accounts that get created (ie. _01 suffixed) somehow that are configured to authenticate via LDAP.. There really should be a way for the administrator to at least change the authentication method for a user.

Does anyone have an idea of what SQL tables (besides xdat_user) might be behind all this? We'd like to experiment on our dev server with trying to repair some of these accounts.

Thanks,

-Eli

[Moore, Charlie]

Hi Eli,

I don't have a good answer for this, but some clarification would be useful. From your earlier message, are you still on XNAT 1.6.5? As of XNAT 1.8.1, the user management dialog should actually allow you to see some (all?) of this information in the UI (see https://issues.xnat.org/browse/XNAT-6683 for details).

Thanks,

Charlie

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of elijah....@gmail.com <elijah....@gmail.com>

Sent: Tuesday, October 26, 2021 2:44 PM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] Change account from database to LDAP authentication

 

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/7bebf670-b426-4ddf-91f9-a725e2856081n%40googlegroups.com.

[Herrick, Rick]

Yes, the table you’re looking for is xhbm_xdat_user_auth. The relationship between a particular authentication provider, an account on that provider, and a local XNAT account is defined by four columns there:

 

• auth_method is the ID of the authentication provider implementation and is defined in the authentication provider plugin. For example, the LDAP plugin is ldap, the OpenID plugin is openid.
• auth_method_id is the configuration for a specific provider instance. You can have multiple openid providers, for instance, like google or github, which have the same configuration parameters, just with different values.
• auth_user is the name or ID for an account on the specific provider instance, so e.g. your email address on an LDAP server or github profile for OpenID.
• xdat_username maps to the login column in xdat_user.

 

You’ll have multiple entries in xhbm_xdat_user_auth for each distinct combination of auth_method and auth_method_id, but the combination of auth_method, auth_method_id, and auth_user is unique. You can modify that table so that the auth_method, auth_method_id, and auth_user rows point to the desired row in xdat_user by changing the value of xdat_username.

 

-- 

Rick Herrick

XNAT Architect/Developer

Computational Imaging Laboratory

Washington University School of Medicine

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/7bebf670-b426-4ddf-91f9-a725e2856081n%40googlegroups.com.

[elijah....@gmail.com]

Thanks Rick, we'll try that out.

Charlie, just to clarify, we're moving to 1.8.3 from 1.6.5. That includes importing over the SQL backup, syncing the "data" folders (archive/prearchive/build, etc) and deploying the war file. Most of the workload is trying to fill in the 1.6.5 gaps... Yes, we can see that information in 1.8.3, but as far as I can tell it's not possible to edit authentication methods once they've been locked into an account. So we have localdb accounts that are supposed to be LDAP accounts, and vice versa. The "LDAP account linking" process also seems somewhat finicky...

For instance, when someone tries to log in to their LDAP account (Login.vm) for the first time, it doesn't take them to the "account linking option" page... instead it takes them to ExternalRegisterLogin.vm, and prompts them to log in again, with no explanation.

But we'll see if we can repair these accounts using the table Rick mentioned. I know editing the SQL table manually is not a great idea, but there's no other way to edit authentication methods.

[elijah....@gmail.com]

Looks like we were able to repair at least one account that had not been previously used for anything. We'll look into what happens if we try to modify users who logged in with a mixed case username. Not a big deal, but we'd prefer the user login to be case insensitive.... It seems like a lot of issues stem from that. Users have trouble logging in, so they try a bunch of different cases and it seems like XNAT automatically creates those accounts.

Is there a good way to force username to be lower case after being input to Login.vm? That way users could login with whatever case they wanted, and it would always find the right account.

-Eli

[elijah....@gmail.com]

We also have LDAP accounts that are in use with mixed case login usernames on XNAT... it would be ideal to fix those (force lowercase for consistency), but again, not likely since they are already involved in projects etc...

-Eli