Login Case Sensitivity

Home » CentOS » Login Case Sensitivity
CentOS 12 Comments

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-

12 thoughts on - Login Case Sensitivity

  • FHDATA wrote:

    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.

  • 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:

    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.

  • 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.

  • 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:

    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:

    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

  • 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.

  • Stephen John Smoogen wrote:
    SHOULD avoid defining mailboxes where the Local-part requires (or
    uses) the Quoted-string form or where the Local-part is 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:

    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.

  • https://tools.ietf.org/html/rfc5321

    Updated by: 7504 DRAFT STANDARD
    Errata Exist Network Working Group J. Klensin Request for Comments: 5321 October 2008
    Obsoletes: 2821
    Updates: 1123
    Category: Standards Track

    . . .
    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.
    . . .

    Case munging of the local part is handled by the local delivery agent in my experience. The Cyrus LMTP service can be, and often is, configured to force lower case munging (imapd.conf
    ‘lmtp_downcase_rcpt: 1’) of the local part. That decision is site specific.