Bugzilla – Bug 2197
Should the client send username unmodified or lowercased?
Last modified: 2012-11-28 11:29:29
You need to
before you can comment on or make changes to this bug.
A few other arguments to stop fiddling with the username on the client side:
- You lose information that you might not be able to get back. If the users are
well aware of the case sensitivity, and enter their user name correctly, then
ThinLinc is currently unable to get that user name as the client never sends
- The same user name transformation the client does needs to be implemented in
bug 2715 as well, making it more difficult to turn off the transformation the
day we decide we want to do so.
I strongly believe that having this in tlclient is solving the problem at the
wrong place. If the administrator uses an authentication system that doesn't
match his requirements, then a workaround should be placed as close to that
authentication system as possible (e.g. a transforming proxy or some special
Another argument against lower casing at the client is the whole mess with
There is no one true way of mapping upper and lower case letters. For example,
the Turkish "I" is not the upper case version of the Turkish "i". This means
that you cannot lower case a string without knowing if the "I" is English or
To solve this, all systems involved need to agree on the locale used. ThinLinc
uses the locale it gets from the environment, but there is no handshake to
synchronise that with the authentication server.
To make things worse, many authentication systems have not properly specified
how case is handled. For LDAP it was originally implementation defined. Since
RFC 3454, there is a locale independent mapping table.
It is unknown which mappings popular systems like OpenLDAP, eDirectory and
Active Directory use, or if they are dependent on system settings.
The practical result of this mess is that "Åsa" can only login provided that
either both ThinLinc and the authentication system agree that "Å" does not have
a lower case, or that the authentication system is aware of the "Å"-"å" mapping
(making any changes on the client irrelevant). Formally, the client's mapping
table must be a subset of the authentication system's.
The server side issue is handled on bug 2753.
For 2.1.0, we will not change the current client behaviour of doing lowercase.
Long-term, we might want to change this, but in that case, we need to start
with investigating which NSS/PAM modules that are case sensitive, and perhaps
fix those that are.
We should also fill in any customer feedback wrt this issue on this bug.
I believe that this should be configurable, and the default should be not to
change the case. Configurable only by configuration file / registry; not in the
Configuration option added in r25554.
Documentation added in r25556. This should complete the bug - tester should
test actual functionality, and also make sure we alert customers of this change
via relevant channels (mailing list, release notes etc).
auth.xml - refers to case insensitive username as a limitation of ThinLinc
(In reply to comment #15)
> auth.xml - refers to case insensitive username as a limitation of ThinLinc
Fixed in r26035.
Reviewed the commits and it do look fine, verified with client build 3680 that
toggle of the bit LOWERCASE_LOGIN_NAME works as expected and docs do now look