hello,
some users' login fails since they type upper case for their user ids ,etc ...
how can case sensitivity be disabled so they can login with mix of upper and lower case?
this is what i tried:
in /etc/sssd/sssd.conf i tested this below
[domain/default] case_sensitive = false
i stopped sssd, deleted all inside /var/sss/db and started sssd but that did not help ....
thank you, F-
FHDATA wrote:
some users' login fails since they type upper case for their user ids ,etc ...
Wouldn't it be better to explain to the users that the userid is case sensitive? You probably don't want a system where Fhdata, FHData and FHDATA are all possible and are different users.
On 09/05/2017 06:01 PM, Yves Bellefeuille wrote:
FHDATA wrote:
some users' login fails since they type upper case for their user ids ,etc ...
Wouldn't it be better to explain to the users that the userid is case sensitive? You probably don't want a system where Fhdata, FHData and FHDATA are all possible and are different users.
Normally, it's a failure to respond to a technical question by instead telling someone how to administer their system(s) or recommending different software. But in this instance I have to agree with Yves. For even if you, fhdata, were to successfully change system handling of userid for sssd, you would then have to allow the same sort of policy for other services such as email and news. Userids could be used also in databases which could be then corrupted. Problems could be introduced also into the various logs. If, as is likely the case, you are not the only sysadmin on the system(s), you would also be creating problems for the other sysadmins, now and into the future. I think it would also be a disservice to users, for case-insensitive userids is not what they'll find on web sites and web services throughout the rest of the world, even on their own phones. So I'd agree, in this instance you should stay with the standard and explain to users that there ids are case sensitive.
On 9/6/2017 3:45 AM, ken wrote:
I think it would also be a disservice to users, for case-insensitive userids is not what they'll find on web sites and web services throughout the rest of the world, even on their own phones.
I agree with you on other points, but beware of this one. I've discovered that game logins, notably Blizzard, are case-insensitive. It's quite frustrating. (I also hate websites that reject spaces in passwords.) Then there's sites that reject plus signs in email and use your email as your account name, which frustrates anti-spam measures and attempts to make your account name harder to guess by adding a "disposable" address tag (eg. shiva+centoslistexample@sewingwitch.com).
Let savvy users make their credentials harder to guess.
Kenneth Porter wrote:
On 9/6/2017 3:45 AM, ken wrote:
I think it would also be a disservice to users, for case-insensitive userids is not what they'll find on web sites and web services throughout the rest of the world, even on their own phones.
I agree with you on other points, but beware of this one. I've discovered that game logins, notably Blizzard, are case-insensitive. It's quite frustrating. (I also hate websites that reject spaces in passwords.) Then there's sites that reject plus signs in email and use your email as your account name, which frustrates anti-spam measures and attempts to make your account name harder to guess by adding a "disposable" address tag (eg. shiva+centoslistexample@sewingwitch.com).
Let savvy users make their credentials harder to guess.
Plus signs in email addresses can have special meanings, depending on the configuration of the MTA (or MTAs in the path), so it makes sense to me to reject them.
(I don´t remember what they were used for or I would provide a suitable link to the exim documentation ...)
Another thing is that the admin should be able to specify which characters should be allowed/forbidden in file names. I really don´t understand why that isn´t possible; I consider it a requirement.
On 5 September 2017 at 17:27, FHDATA fhdata@unm.edu wrote:
hello,
some users' login fails since they type upper case for their user ids ,etc ...
how can case sensitivity be disabled so they can login with mix of upper and lower case?
this is what i tried:
in /etc/sssd/sssd.conf i tested this below
[domain/default] case_sensitive = false
i stopped sssd, deleted all inside /var/sss/db and started sssd but that did not help ....
case sensitivity for user accounts is considered implementation dependent from the early days of Unix. However most Unixes from the late 1970's onward incorporated that user accounts were case sensitive in login. The later POSIX standards to try and formalize various divergences, kept it as being 'site dependent'. This was always problematic because DNS hostnames and email addresses in the RFC standards were case insensitive so that you could have accounts like abc, Abc, and ABC but only one of them would get email. LDAP sort of cuts a path between POSIX and RFC where depending on the LDAP servers configuration, it is either case sensitive or case insensitive. The client has little control over this because sending something the AD or LDAP server will not parse will give an error.
The second issue is that login checks against what getent the account name is which is before LDAP gives an answer. Long long ago, you could look at using pam_regex to make sure that all accounts were seen as lower case so that when passed to LDAP they matched. However I haven't looked at that in close to 2 decades so I have no idea if it is still valid.
On 09/07/2017 08:11 AM, Stephen John Smoogen wrote:
This was always problematic because DNS hostnames and email addresses in the RFC standards were case insensitive
Not quite. SMTP is required to treat the "local-part" of the RCPT argument as case-sensitive, and to preserve case when relaying mail. The destination is allowed to treat addresses according to local policy, but in general SMTP is case sensitive with regard to the user identifier.
Gordon Messmer wrote:
On 09/07/2017 08:11 AM, Stephen John Smoogen wrote:
This was always problematic because DNS hostnames and email addresses in the RFC standards were case insensitive
Not quite. SMTP is required to treat the "local-part" of the RCPT argument as case-sensitive, and to preserve case when relaying mail. The destination is allowed to treat addresses according to local policy, but in general SMTP is case sensitive with regard to the user identifier.
Last time I checked, RFCs said that local parts *should not* be case sensitive, and cyrus defaulted to treat them case sensitive, which is a default that usually needs to be changed because senders of messages tend to not pay any attention to the case sensitiveness of recipient addresses at all, which then confuses them like any other error.
Am 07.09.2017 um 20:07 schrieb hw:
Gordon Messmer wrote:
On 09/07/2017 08:11 AM, Stephen John Smoogen wrote:
This was always problematic because DNS hostnames and email addresses in the RFC standards were case insensitive
Not quite. SMTP is required to treat the "local-part" of the RCPT argument as case-sensitive, and to preserve case when relaying mail. The destination is allowed to treat addresses according to local policy, but in general SMTP is case sensitive with regard to the user identifier.
Last time I checked, RFCs said that local parts *should not* be case sensitive, and cyrus defaulted to treat them case sensitive, which is a default that usually needs to be changed because senders of messages tend to not pay any attention to the case sensitiveness of recipient addresses at all, which then confuses them like any other error.
The relevant part from the RFC:
https://www.ietf.org/rfc/rfc5321.txt
2.4. General Syntax Principles and Transaction Model
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part (SMTP Extensions may explicitly specify case-sensitive elements). That is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning. The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive.
Alexander
On 7 September 2017 at 16:07, Alexander Dalloz ad+lists@uni-x.org wrote:
Am 07.09.2017 um 20:07 schrieb hw:
Gordon Messmer wrote:
On 09/07/2017 08:11 AM, Stephen John Smoogen wrote:
This was always problematic because DNS hostnames and email addresses in the RFC standards were case insensitive
Not quite. SMTP is required to treat the "local-part" of the RCPT argument as case-sensitive, and to preserve case when relaying mail. The destination is allowed to treat addresses according to local policy, but in general SMTP is case sensitive with regard to the user identifier.
Last time I checked, RFCs said that local parts *should not* be case sensitive, and cyrus defaulted to treat them case sensitive, which is a default that usually needs to be changed because senders of messages tend to not pay any attention to the case sensitiveness of recipient addresses at all, which then confuses them like any other error.
The relevant part from the RFC:
https://www.ietf.org/rfc/rfc5321.txt
2.4. General Syntax Principles and Transaction Model
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part (SMTP Extensions may explicitly specify case-sensitive elements). That is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning. The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive.
Thanks for the clarification to my original email. I misremembered RFC821 and thought it was for the entire part..
Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and SMTP implementations must take case to preserve the case of user names as they appear in mailbox arguments. Host names are not case sensitive.
Alexander
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Stephen John Smoogen wrote:
On 7 September 2017 at 16:07, Alexander Dalloz ad+lists@uni-x.org wrote:
Am 07.09.2017 um 20:07 schrieb hw:
Gordon Messmer wrote:
On 09/07/2017 08:11 AM, Stephen John Smoogen wrote:
This was always problematic because DNS hostnames and email addresses in the RFC standards were case insensitive
Not quite. SMTP is required to treat the "local-part" of the RCPT argument as case-sensitive, and to preserve case when relaying mail. The destination is allowed to treat addresses according to local policy, but in general SMTP is case sensitive with regard to the user identifier.
Last time I checked, RFCs said that local parts *should not* be case sensitive, and cyrus defaulted to treat them case sensitive, which is a default that usually needs to be changed because senders of messages tend to not pay any attention to the case sensitiveness of recipient addresses at all, which then confuses them like any other error.
The relevant part from the RFC:
https://www.ietf.org/rfc/rfc5321.txt
2.4. General Syntax Principles and Transaction Model
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part (SMTP Extensions may explicitly specify case-sensitive elements). That is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning. The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive. for maximum interoperability, a host that expects to receive mail
SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case- sensitive.
Thanks for the clarification to my original email. I misremembered RFC821 and thought it was for the entire part..
Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and SMTP implementations must take case to preserve the case of user names as they appear in mailbox arguments. Host names are not case sensitive.
RFC2821, section 4.1.2:
" for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case- sensitive. "
It comes down to that case-preservation is demanded from the implementations of protocols while, pragmatically, local parts are encouraged to be case insensitive.
More than a decade ago, I argued that the default used by cyrus be changed to treat local parts case insensitve. About 2 years ago, that still hadn´t changed.
So everyone deploying cyrus, be aware. Other than that, cyrus always worked flawlessly, and I highly recommend it to everyone needing an IMAP server.
Alexander Dalloz wrote:
Am 07.09.2017 um 20:07 schrieb hw:
Gordon Messmer wrote:
On 09/07/2017 08:11 AM, Stephen John Smoogen wrote:
This was always problematic because DNS hostnames and email addresses in the RFC standards were case insensitive
Not quite. SMTP is required to treat the "local-part" of the RCPT argument as case-sensitive, and to preserve case when relaying mail. The destination is allowed to treat addresses according to local policy, but in general SMTP is case sensitive with regard to the user identifier.
Last time I checked, RFCs said that local parts *should not* be case sensitive, and cyrus defaulted to treat them case sensitive, which is a default that usually needs to be changed because senders of messages tend to not pay any attention to the case sensitiveness of recipient addresses at all, which then confuses them like any other error.
The relevant part from the RFC:
https://www.ietf.org/rfc/rfc5321.txt
2.4. General Syntax Principles and Transaction Model
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part (SMTP Extensions may explicitly specify case-sensitive elements). That is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning. The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive.
That´s the implementation of the protocol, see my previous post, and:
" Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case- insensitive local name. "
also from RFC 2821, section 4.5.1. Of course, this is a special case; I just can´t find the part wich exactly said that local parts should be treated case insensitively beyond what I found in 2821. It´s even possible that it was changed.
If you really want to treat local parts case sensitive, you can do so. I´d advise against it.
-
Alexander Dalloz -
FHDATA -
Gordon Messmer -
hw -
ken -
Kenneth Porter -
Stephen John Smoogen -
Yves Bellefeuille