You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@guacamole.apache.org by "Magnus Lübeck (Jira)" <ji...@apache.org> on 2022/11/21 23:35:00 UTC

[jira] [Commented] (GUACAMOLE-1239) Make usernames case insensitive in DB

    [ https://issues.apache.org/jira/browse/GUACAMOLE-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636931#comment-17636931 ] 

Magnus Lübeck commented on GUACAMOLE-1239:
------------------------------------------

I am still willing to sponsor the development of case insensitive usernames, if someone is inclined to help.

> Make usernames case insensitive in DB 
> --------------------------------------
>
>                 Key: GUACAMOLE-1239
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1239
>             Project: Guacamole
>          Issue Type: Improvement
>          Components: guacamole-auth-jdbc, guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-auth-ldap
>            Reporter: Magnus Lübeck
>            Priority: Minor
>
> [~cameronp] already summarized this well in GUACAMOLE-404:
>  
> Quote:
> "We have ldap auth working for us via active directory. We have issues with case senstivity around logins. For example most users have no idea if their username is
> User.Name
> or USER.NAME or whatever. - active directory doesnt care about case, and neither does ldap authentication.
> But when they log in to guac and do not match the case of their login exactly, guac allows them to log in, but they just don't have any machines to connect to.
> Wondering if it could be made to either fail the logins if it doesn't match correct case, or ignore case when matching the username in the local guac db."
>  
> So, when I ran across GUACAMOLE-404, and this email [https://www.mail-archive.com/dev@guacamole.apache.org/msg03715.html] where [~vnick] discuss this topic in depth, I realized that I need to chip in my point of view. In the documentation it is mentioned that one can restrict user login, to avoid confusion that a user can log in per LDAP but not have any connections, http://guacamole.incubator.apache.org/doc/gug/jdbc-auth.html#jdbc-auth-restrict.
> I am not sure where I would start lobbying for either asking for a default case insensitive username management, or the option to make the Postgresql/Mysql/etc usernames case insensitive. I would happily chip in time, money, or other stimulus to bring this discussion further.
>  
> This writeup from google is a text I have visited from time to time, as I think it is well written and makes many points in a clear manner.
> [https://cloud.google.com/blog/products/gcp/12-best-practices-for-user-account]
>  
> Point 11: Make user IDs case insensitive
> Quote:
> "Your users don't care and may not even remember the exact case of their username. Usernames should be fully case-insensitive. It's trivial to store usernames and email addresses in all lowercase and transform any input to lowercase before comparing.
> Smartphones represent an ever-increasing percentage of user devices. Most of them offer autocorrect and automatic capitalization of plain-text fields. Preventing this behavior at the UI level might not be desirable or completely effective, and your service should be robust enough to handle an email address or username that was unintentionally auto-capitalized."
>  
> I had a very long discussion about this with a work colleague today. He has to support a group of customers, of which we get a list of CAPITALIZED usernames to import into our Active Directory domain controller. These users are quite used to work in an environment where they don't have to care. I have observed our customers log in and many users either log in with their username in lowercase, some log in with their username's first letter CAPITALIZED. Very rarely do they log in with all caps.
>  
> To make matters a bit worse, is that we integrate Guacamole with oauth2_proxy in front of it. Oauth2_proxy sends the users first to our KeyCloak installation, which happily authenticates the user with any permutation they choose to enter. Since we do want to have the users log into the RDP servers with their own credentials they are asked to log in again (a 2nd time, since we don't get the password through otherwise). It is very confusing for our users that they can log into KeyCloak but not into Guacamole.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)