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 it. - 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 nss module).
Another argument against lower casing at the client is the whole mess with locales. 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 Turkish. 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 GUI.
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 client.
(In reply to comment #15) > auth.xml - refers to case insensitive username as a limitation of ThinLinc > client. 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 ok.
