LDAP: Error when DistiguishedName contains non-English characters #2033

New Issue

OVERLORD · 2026-02-05T02:38:56+03:00

OVERLORD commented

2026-02-05 02:38:56 +03:00

Originally created by @Kurbitz on GitHub (Jan 12, 2021).

Describe the bug
Bug in LDAP Integration. An exception is thrown when users who are members of AD groups who's DistinguishedName contain non-English characters try to log in.

ErrorException: Undefined offset: 0

Laravel log:
https://flareapp.io/share/Bm01pADP#F55

It appears $dnComponents is unexpectedly null because ldap_explode_dn can't handle the non-English characters

Steps To Reproduce
Steps to reproduce the behavior:

Ensure LDAP is in use and set "LDAP_GROUP_ATTRIBUTE" to "memberOf".
Assign a user to an Active Directory group containing any non-English character (I've only tested å, ä, ö and ß but I suspect this is an ASCII/ANSI issue).
Sign in as user.

Expected behavior
The LDAP integration checks for any relevant group-memberships and allows the user to sign in.

Your Configuration (please complete the following information):

Exact BookStack Version (Found in settings): v0.31.1
PHP Version: PHP 7.3.25
Hosting Method (Nginx/Apache/Docker): Docker

Originally created by @Kurbitz on GitHub (Jan 12, 2021). **Describe the bug** Bug in LDAP Integration. An exception is thrown when users who are members of AD groups who's DistinguishedName contain non-English characters try to log in. ErrorException: Undefined offset: 0 Laravel log: https://flareapp.io/share/Bm01pADP#F55 It appears $dnComponents is unexpectedly null because ldap_explode_dn can't handle the non-English characters **Steps To Reproduce** Steps to reproduce the behavior: 1. Ensure LDAP is in use and set "LDAP_GROUP_ATTRIBUTE" to "memberOf". 2. Assign a user to an Active Directory group containing any non-English character (I've only tested å, ä, ö and ß but I suspect this is an ASCII/ANSI issue). 3. Sign in as user. **Expected behavior** The LDAP integration checks for any relevant group-memberships and allows the user to sign in. **Your Configuration (please complete the following information):** - Exact BookStack Version (Found in settings): v0.31.1 - PHP Version: PHP 7.3.25 - Hosting Method (Nginx/Apache/Docker): Docker

OVERLORD closed this issue

2026-02-05 02:38:59 +03:00

OVERLORD commented

2026-02-05 02:39:10 +03:00

@csongs commented on GitHub (Jan 14, 2021):

Hi Kurbitz,
I had the same problem before. see #2415
Author writes a tool can encode any non-ascii characters, https://jsfiddle.net/ssddanbrown/4nkwuxj8/3/

@csongs commented on GitHub (Jan 14, 2021): Hi Kurbitz, I had the same problem before. see #2415 Author writes a tool can encode any non-ascii characters, https://jsfiddle.net/ssddanbrown/4nkwuxj8/3/

OVERLORD commented

2026-02-05 02:39:13 +03:00

@ssddanbrown commented on GitHub (Jan 15, 2021):

Thanks for reporting @Kurbitz,

I'm not so sure it's due to non-English characters, Would have thought we have seen this sooner and, as @csongs has mentioned, others are using groups with non-ascii chars.

Tested on command line, ldap_explode_dn seems to be okay with the characters:

php > print_r(ldap_explode_dn('cn=åäöß, ou=äö', 0));
Array
(
    [count] => 2
    [0] => cn=\C3\A5\C3\A4\C3\B6\C3\9F
    [1] => ou=\C3\A4\C3\B6
)

I could only really get ldap_explode_dn to not return a 0 index when the dn is genuinely invalid or empty.

We do need to have more graceful handling in the code to handle this case either way.

@ssddanbrown commented on GitHub (Jan 15, 2021): Thanks for reporting @Kurbitz, I'm not so sure it's due to non-English characters, Would have thought we have seen this sooner and, as @csongs has mentioned, others are using groups with non-ascii chars. Tested on command line, `ldap_explode_dn` seems to be okay with the characters: ```shell php > print_r(ldap_explode_dn('cn=åäöß, ou=äö', 0)); Array ( [count] => 2 [0] => cn=\C3\A5\C3\A4\C3\B6\C3\9F [1] => ou=\C3\A4\C3\B6 ) ``` I could only really get `ldap_explode_dn` to not return a `0` index when the dn is genuinely invalid or empty. We do need to have more graceful handling in the code to handle this case either way.

OVERLORD commented

2026-02-05 02:39:20 +03:00

@Swoy commented on GitHub (Jan 21, 2021):

Could this be related to the .env file? The .env file has mime of us_ascii, this has caused issues with passwords as well (mysql and ldap login) since you cannot use non-ascii in that file.

@Swoy commented on GitHub (Jan 21, 2021): Could this be related to the .env file? The .env file has mime of us_ascii, this has caused issues with passwords as well (mysql and ldap login) since you cannot use non-ascii in that file.

OVERLORD commented

2026-02-05 02:39:25 +03:00

@Vivian-31 commented on GitHub (Jan 22, 2021):

Same issue with us, every ldap member with "not english characters" (é, ä, ..) can connect only one, the second time it says that an user with this email adress already exists. If we change the name in the ldap and replace the characters everything works fine

@Vivian-31 commented on GitHub (Jan 22, 2021): Same issue with us, every ldap member with "not english characters" (é, ä, ..) can connect only one, the second time it says that an user with this email adress already exists. If we change the name in the ldap and replace the characters everything works fine

OVERLORD commented

2026-02-05 02:39:31 +03:00

@ssddanbrown commented on GitHub (Jan 23, 2021):

Hi @Vivian-31, What you're describing sounds like a different issue, more like issue #90

@ssddanbrown commented on GitHub (Jan 23, 2021): Hi @Vivian-31, What you're describing sounds like a different issue, more like issue #90

OVERLORD commented

2026-02-05 02:39:36 +03:00

@ssddanbrown commented on GitHub (Feb 8, 2021):

Another thing that could lead to this issue, is not having LDAP_VERSION=3 set otherwise the system may default to old non-utf8-by-default standards.

Since there's been no folow-up from the original issue creator after the above guidance, I'll close this off.

@ssddanbrown commented on GitHub (Feb 8, 2021): Another thing that could lead to this issue, is not having `LDAP_VERSION=3` set otherwise the system may default to old non-utf8-by-default standards. Since there's been no folow-up from the original issue creator after the above guidance, I'll close this off.

OVERLORD commented

2026-02-05 02:39:41 +03:00

@Kurbitz commented on GitHub (Mar 12, 2021):

Hi! Sorry for responding so late. And thanks for all the time you put into this project @ssddanbrown :)
Setting LDAP_VERSION=3 in the .env file solved the issue.
Thanks again!

@Kurbitz commented on GitHub (Mar 12, 2021): Hi! Sorry for responding so late. And thanks for all the time you put into this project @ssddanbrown :) Setting LDAP_VERSION=3 in the .env file solved the issue. Thanks again!

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#2033