[
https://issues.apache.org/jira/browse/GUACAMOLE-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888457#comment-17888457
]
Nick Couchman commented on GUACAMOLE-1239:
--
[~mjumper]: Thanks, working on implementing these changes.
> Make usernames case insensitive in DB
> --
>
> Key: GUACAMOLE-1239
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1239
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation, guacamole-auth-jdbc,
> guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-auth-ldap
>Reporter: Magnus Lübeck
>Assignee: Nick Couchman
>Priority: Minor
> Fix For: 1.6.0
>
>
> [~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)
