Users with special characters in their full name are not able to log into JIRA

Still need help?

The Atlassian Community is here for you.

Ask the community

This article only applies to the Atlassian server platform. Learn more about the differences between cloud and server.

Problem

    • Users who have special characters in their full name ( eg. š, ē, ā, ī, ņ, ū, etc ) are not able to log into JIRA
    • Users without special characters are able to log in without any issues.
    • The following appears in the atlassian-jira-security.log 

2016-02-10 12:25:50,464 http-bio-443-exec-28 XXXXXX 745x137142x1 1006pi1 10.30.51.31 /rest/gadget/1.0/login login : 'XXXXX' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.
2016-02-10 12:25:50,476 http-bio-443-exec-28 XXXXXX 745x137142x1 1006pi1 10.30.51.31 /rest/gadget/1.0/login The user 'XXXXX' has FAILED authentication.  Failure count equals 1

Diagnosis

Environment

  • Users are from a specific LDAP called The Domino LDAP by IBM
  • using a simple tool where they create LDIF file - when in string is some Unicode symbol it to base64.

Diagnostic Steps

  • To reproduce the issue, the affected user needs to have special characters for the first letter of the surname ( givenName ) attribute for example :

    Kaspars Šmits
  • Users without special characters for the first letter of the surname ( givenName ) attribute are not affected for example :

    Mārcis Beržinskis
  • cwd_user table suggest that both users using special characters in the Full Name
  • app_user data suggest user_key using special characters for Mārcis Beržinskis user but lower_user_name remain no special characters
  • Checking the database, everything looks OK

    GHS-33147=# select * from app_user where lower_user_name = lower('Kaspars.Smits@example.com');
      id   |       user_key       |   lower_user_name
    -------+----------------------+----------------------
     11400 | kaspars.smits@example.com | kaspars.smits@example.com
    (1 row)
    
    GHS-33147=# select * from app_user where lower_user_name = lower('Marcis.Berzinskis@example.com');
      id   |     user_key      |     lower_user_name
    -------+-------------------+--------------------------
     10401 | mārcis beržinskis | marcis.berzinskis@example.com
    (1 row)
    
    GHS-33147=# select * from cwd_user where lower_user_name in ('kaspars.smits@example.com', 'marcis.berzinskis@example.com');
      id   | directory_id |        user_name              |     lower_user_name           | active |        created_date        |        updated_date
    -------+--------------+-------------------------------+-------------------------------+--------+----------------------------+--------------------------
     10961 |        10001 | Marcis.Berzinskis@example.com | marcis.berzinskis@example.com |      1 | 2016-01-28 16:26:41.228+11 | 2016-03-04 14:07:43.513+1
     12728 |        10001 | Kaspars.Smits@example.com     | kaspars.smits@example.com     |      1 | 2016-01-29 14:04:48.432+11 | 2016-02-09 11:12:27.007+1
    (2 rows)
  • If username ("kaspars šmits") tries to login the LDAP directly  with lowercase letters, then LDAP bind doesn't work, if username ("Kaspars Šmits") trieds to login the LDAP directly with uppercase letters, then LDAP bind does work.
  • If the username is ("mārcis beržinskis") tries to login the LDAP directly , the LDAP bind does works in both case (lowercase and uppercase)

Cause

  • The LDAP server is not comparing non-ASCII characters case insensitively but is comparing ASCII characters case insensitively
  • The LDAP server will need to be configured so that the non-ASCII characters are compared ignoring case
  • This issue needs to be resolved on the LDAP side as the issue is not specifically within JIRA (testing with something like ldapsearch outside of JIRA will show the same problem)

Workaround

Use another LDAP directory preferably if is included in the Directory Type when configuring LDAP User Directory: 

 

Last modified on Apr 5, 2016

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.