Problem with LDAP Auth and Umlauts #1304

New Issue

OVERLORD · 2026-02-05T00:33:26+03:00

OVERLORD commented

2026-02-05 00:33:26 +03:00

Originally created by @MarkusEischeid on GitHub (Aug 14, 2019).

Describe the bug
When using LDAP Auth users with Umlauts (ä ö ü) in their names can only log in once. On second login they get an error "user exists".

Steps To Reproduce
Steps to reproduce the behavior:

Configure LDAP auth. Create an LDAP user with Umlauts in the name
Login
Logoff
Login again

Expected behavior
User login should work

Your Configuration (please complete the following information):
Settings in .env

LDAP_USER_FILTER=(&(sAMAccountName=${user}))
LDAP_DISPLAY_NAME_ATTRIBUTE=cn

Suggested Solution
"uid" and "name" should be encoded with utf8_encode in the LdapService.php like this:

 public function getUserDetails($userName)
    {
        $emailAttr = $this->config['email_attribute'];
        $displayNameAttr = $this->config['display_name_attribute'];

        $user = $this->getUserWithAttributes($userName, ['cn', 'uid', 'dn', $emailAttr, $displayNameAttr]);

        if ($user === null) {
            return null;
        }

        $userCn = $this->getUserResponseProperty($user, 'cn', null);
        return [
            'uid'   => utf8_encode($this->getUserResponseProperty($user, 'uid', $user['dn'])),
            'name'  => utf8_encode($this->getUserResponseProperty($user, $displayNameAttr, $userCn)),
            'dn'    => $user['dn'],
            'email' => $this->getUserResponseProperty($user, $emailAttr, null),
        ];
    }

This is what solved the problem on my installation.

Originally created by @MarkusEischeid on GitHub (Aug 14, 2019). **Describe the bug** When using LDAP Auth users with Umlauts (ä ö ü) in their names can only log in once. On second login they get an error "user exists". **Steps To Reproduce** Steps to reproduce the behavior: 1. Configure LDAP auth. Create an LDAP user with Umlauts in the name 2. Login 3. Logoff 4. Login again **Expected behavior** User login should work **Your Configuration (please complete the following information):** Settings in .env ``` LDAP_USER_FILTER=(&(sAMAccountName=${user})) LDAP_DISPLAY_NAME_ATTRIBUTE=cn ``` **Suggested Solution** "uid" and "name" should be encoded with `utf8_encode` in the `LdapService.php` like this: ```php public function getUserDetails($userName) { $emailAttr = $this->config['email_attribute']; $displayNameAttr = $this->config['display_name_attribute']; $user = $this->getUserWithAttributes($userName, ['cn', 'uid', 'dn', $emailAttr, $displayNameAttr]); if ($user === null) { return null; } $userCn = $this->getUserResponseProperty($user, 'cn', null); return [ 'uid' => utf8_encode($this->getUserResponseProperty($user, 'uid', $user['dn'])), 'name' => utf8_encode($this->getUserResponseProperty($user, $displayNameAttr, $userCn)), 'dn' => $user['dn'], 'email' => $this->getUserResponseProperty($user, $emailAttr, null), ]; } ``` This is what solved the problem on my installation.

OVERLORD added the 📖 Docs Update 🚪 Authentication 🌍 Translations labels 2026-02-05 00:33:26 +03:00

OVERLORD closed this issue

2026-02-05 00:33:27 +03:00

OVERLORD commented

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

@watschi commented on GitHub (Mar 13, 2020):

Hi,
we ran into the same issue today, the fix mentioned above by @MarkusEischeid helped.
On creation of a user, its external_auth_id attribute gets cut off at the umlaut, therefore it won't match on the next logon.

The same problem also applies to groups containing umlauts (as discussed in the php function reference to ldap_explode_dn). If a user belongs to any group containing umlauts, any attempt to logon will fail if group sync is enabled.

Encoding the groups DN in LdapService.php as below fixes this.

    protected function groupFilter(array $userGroupSearchResponse): array
    {
        $groupsAttr = strtolower($this->config['group_attribute']);
        $ldapGroups = [];
        $count = 0;

        if (isset($userGroupSearchResponse[$groupsAttr]['count'])) {
            $count = (int)$userGroupSearchResponse[$groupsAttr]['count'];
        }

        for ($i = 0; $i < $count; $i++) {
            $dnComponents = $this->ldap->explodeDn(utf8_encode($userGroupSearchResponse[$groupsAttr][$i]), 1);
            if (!in_array($dnComponents[0], $ldapGroups)) {
                $ldapGroups[] = $dnComponents[0];
            }
        }

        return $ldapGroups;
    }

A way better fix than patching LdapService.php, however, is to set LDAP_VERSION=3 in .env if possible.
According to this Stack Overflow post, LDAPv3 supports UTF-8 by default. At least in our Active Directory environment using LDAPv3 was suffice to correctly parse any groups containing special chars.

Maybe a recommendation to set LDAP_VERSION=3 should also be added to the LDAP Authentication documentation (not just in the Active Directory specific part)?
Currently there is no further explanation regarding the LDAP_VERSION in the non-AD specific documentation and after initial testing through someone without umlauts in his name/groups everything will seem to work ok.

According to the OpenLDAP admin guide LDAPv2 is historic, should be avoided and is disabled at least in OpenLDAP by default.

I'm happy to open a PR to the docs if desired.

@watschi commented on GitHub (Mar 13, 2020): Hi, we ran into the same issue today, the fix mentioned above by @MarkusEischeid helped. On creation of a user, its external_auth_id attribute gets cut off at the umlaut, therefore it won't match on the next logon. The same problem also applies to groups containing umlauts (as discussed in the php function reference to [ldap_explode_dn](https://www.php.net/manual/de/function.ldap-explode-dn.php)). If a user belongs to any group containing umlauts, any attempt to logon will fail if group sync is enabled. Encoding the groups DN in LdapService.php as below fixes this. ```php protected function groupFilter(array $userGroupSearchResponse): array { $groupsAttr = strtolower($this->config['group_attribute']); $ldapGroups = []; $count = 0; if (isset($userGroupSearchResponse[$groupsAttr]['count'])) { $count = (int)$userGroupSearchResponse[$groupsAttr]['count']; } for ($i = 0; $i < $count; $i++) { $dnComponents = $this->ldap->explodeDn(utf8_encode($userGroupSearchResponse[$groupsAttr][$i]), 1); if (!in_array($dnComponents[0], $ldapGroups)) { $ldapGroups[] = $dnComponents[0]; } } return $ldapGroups; } ``` A way better fix than patching LdapService.php, however, is to set `LDAP_VERSION=3` in `.env` if possible. According to [this](https://stackoverflow.com/questions/11035359/foreign-characters-and-ldap-what-encoding-charset-does-ldap-expect) Stack Overflow post, LDAPv3 supports UTF-8 by default. At least in our Active Directory environment using LDAPv3 was suffice to correctly parse any groups containing special chars. Maybe a recommendation to set `LDAP_VERSION=3` should also be added to the LDAP Authentication documentation (not just in the Active Directory specific part)? Currently there is no further explanation regarding the `LDAP_VERSION` in the non-AD specific documentation and after initial testing through someone without umlauts in his name/groups everything will seem to work ok. According to the [OpenLDAP admin guide](https://www.openldap.org/doc/admin24/intro.html#What%20is%20the%20difference%20between%20LDAPv2%20and%20LDAPv3) LDAPv2 is historic, should be avoided and is disabled at least in OpenLDAP by default. I'm happy to open a PR to the docs if desired.

OVERLORD commented

2026-02-05 00:33:35 +03:00

@ssddanbrown commented on GitHub (Mar 14, 2020):

Thanks so much for investigating this @watschi. I completely agree, The default setup config shown in the docs should have LDAP_VERSION=3 with some added explanation maybe. I didn't realise v2 was so old.

Would absolutely welcome a PR on the docs.

@ssddanbrown commented on GitHub (Mar 14, 2020): Thanks so much for investigating this @watschi. I completely agree, The default setup config shown in the docs should have `LDAP_VERSION=3` with some added explanation maybe. I didn't realise v2 was so old. Would absolutely welcome a PR on the docs.

OVERLORD commented

2026-02-05 00:33:40 +03:00

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

A bit delayed, but docs updated in 49b2d0afbb.

Thanks again @watschi for your efforts here.

@ssddanbrown commented on GitHub (Feb 8, 2021): A bit delayed, but docs updated in https://github.com/BookStackApp/website/commit/49b2d0afbb23e635da6c993840991f4cc82afadc. Thanks again @watschi for your efforts here.

OVERLORD referenced this issue

2026-02-05 03:58:46 +03:00

Table cell keeps info about drawing even if image is gone #2405

OVERLORD referenced this issue

2026-02-05 04:07:07 +03:00

Draw.io broken when used within table cell #2430

Sign in to join this conversation.