Project

General

Profile

Bug #2227

International / UTF-8 characters not working in LDAP configuration

Added by Claude Duvergier almost 8 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
02/22/2012
Due date:
% Done:

100%

Estimated time:
Affected Version:
Affected Architecture:

Description

While trying to configure pfSense to use an LDAP authentication server that use some (french) accentuated characters (é, à, è, etc.) in DNs, I discovered it doesn't work.

Steps to reproduce:

Create (or update) a new LDAP server configuration by using the following DN in "Search scope" or "Authentication containers" field:

ou=Recherche et Développement,dc=mycompany,dc=com

Actual result:

When saving "Authentication Servers" I get the notification-error:

[config.xml]pfSense is restoring the configuration /cf/conf/backup/config-1329926905.xml

System logs says:

Feb 22 18:00:15     php: /system_authservers.php: New alert found: pfSense is restoring the configuration /cf/conf/backup/config-1329926905.xml
Feb 22 18:00:15     php: /system_authservers.php: pfSense is restoring the configuration /cf/conf/backup/config-1329926905.xml
Feb 22 18:00:15     php: /system_authservers.php: XML error: Undeclared entity error at line 223 in /conf/config.xml

And the server configuration is not added/updated

Expected result:

LDAP server configuration created/updated without error

Additional notes:

Looking at /cf/conf/config.xml.bad configuration file I see that the "é" was replaced by "é"

<pfsense>
    [...]
    <system>
        [...]
        <authserver>
            [...]
            <ldap_authcn>ou=Recherche et D&eacute;veloppement</ldap_authcn>
            [...]

Maybe it has to do with the lack of specified encoding no encoding attribute in )?
Maybe values should be placed in CDATA?: <ldap_authcn><![CDATA[ou=Recherche et Développement]]></ldap_authcn>

I ran into that issue by adding a LDAP server for authentication: but maybe the issue is more global?

Associated revisions

Revision a5cd1c5a (diff)
Added by Jim Pingle over 6 years ago

Add LDAP server options to control UTF8-encoding of parameters. Fixes #2227. While I'm here, add a checkbox to prevent the stripping of @ from the LDAP username if the user wants the full name transmitted.

Revision 298020b2 (diff)
Added by Jim Pingle over 6 years ago

Add LDAP server options to control UTF8-encoding of parameters. Fixes #2227. While I'm here, add a checkbox to prevent the stripping of @ from the LDAP username if the user wants the full name transmitted.

Revision bcf4b8cc (diff)
Added by Jim Pingle over 6 years ago

Don't blow up the config if someone enters int'l chars in an LDAP attribute/DN field. Ticket #2227

Revision dc3fc54a (diff)
Added by Jim Pingle over 6 years ago

Don't blow up the config if someone enters int'l chars in an LDAP attribute/DN field. Ticket #2227

History

#1 Updated by Jim Pingle almost 8 years ago

Those characters are invalid to have in XML, and (as you see) must be CDATA escaped. However, not all fields are CDATA escaped in the config. Though we usually reject such characters in fields that are not protected, it seems this is one case we don't have that protection in place.

This will take changes in the backend to handle such characters in that field.

As a quick test, you could add ldap_authcn to the checks in /etc/inc/xmlparse.inc that handle CDATA fields (currently just descr and detail).

#2 Updated by Claude Duvergier almost 8 years ago

I changed two lines of /etc/inc/xmlparse.inc file:

} else if ((substr($ent, 0, 5) == "descr") || (substr($ent, 0, 6) == "detail")) {

if ((substr($ent, 0, 5) == "descr") || (substr($ent, 0, 6) == "detail"))

Changed into:

} else if (($ent == "ldap_authcn") || (substr($ent, 0, 5) == "descr") || (substr($ent, 0, 6) == "detail")) {

if (($ent == "ldap_authcn") || (substr($ent, 0, 5) == "descr") || (substr($ent, 0, 6) == "detail"))

And adding/updating server configuration with "é" character doesn't trigger any error: thanks :)

But when trying to authenticate with an LDAP-user from a container using the "é" (say ou=Recherche et Développement,dc=mycompany,dc=com) it fails and System logs says:

Feb 22 19:22:59     php: /index.php: webConfigurator authentication error for 'cduv' from 192.168.1.141
Feb 22 19:22:59     php: /index.php: webConfigurator authentication error for 'cduv' from 192.168.1.141
Feb 22 19:22:59     php: /index.php: ERROR! Either LDAP search failed, or multiple users were found.
Feb 22 19:22:59     php: /index.php: Search resulted in error: Invalid DN syntax
Feb 22 19:22:59     php: /index.php: Now Searching in server MyCompany, container ou=Recherche et Développement with filter (uid=cduv).
Feb 22 19:22:59     php: /index.php: Now Searching in server MyCompany, container ou=Partenaires with filter (uid=cduv).
Feb 22 19:22:58     php: /index.php: Now Searching in server MyCompany, container ou=Stagiaires with filter (uid=cduv).
Feb 22 19:22:58     php: /index.php: Now Searching in server MyCompany, container ou=Commerciaux with filter (uid=cduv).
Feb 22 19:22:58     php: /index.php: Now Searching for cduv in directory.

If I try with an other LDAP-user account from a container without any special character (say ou=Commerciaux,dc=mycompany,dc=com) it works just fine.

Looks like the "é" is causing problems in the code that handles LDAP search/binding.

#3 Updated by Jim Pingle almost 8 years ago

Someone who knows more about LDAP will have to comment on that one. I just knew the XML bit. :-)

There may be a library or component somewhere underneath that doesn't have proper UTF-8 or related support, The "Invalid DN syntax" error does not come from our code, it is returned by PHP's ldap_error() function:

etc/inc/auth.inc: log_error(sprintf(gettext("Search resulted in error: %s"), ldap_error($ldap)));

You might give a 2.1 snapshot a try (http://iserv.nl/files/pfsense/releng83/) because those use PHP 5.3.x, you may be hitting a PHP 5.2.x issue.

Or it could need utf8_encode()/utf8_decode() somewhere before passing parameters to the LDAP functions.

Just a guess there though.

#4 Updated by Claude Duvergier almost 8 years ago

It was indeed a missing utf8_encode():

I changed source:/etc/inc/auth.inc@184a6ceb#L1054 as following:

1054c1054
<             $search     = @$ldapfunc($ldap,$ldac_split,$ldapfilter);
---
>             $search     = @$ldapfunc($ldap,utf8_encode($ldac_split),$ldapfilter);
1056c1056
<             $search  = @$ldapfunc($ldap,"{$ldac_split},{$ldapbasedn}",$ldapfilter);
---
>             $search  = @$ldapfunc($ldap,utf8_encode("{$ldac_split},{$ldapbasedn}"),$ldapfilter);

And LDAP-based authentication is working just fine by now.

#5 Updated by Jim Pingle over 6 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#7 Updated by Claude Duvergier almost 6 years ago

I'm OK with changes: works fine.

#8 Updated by Chris Buechler almost 6 years ago

  • Status changed from Feedback to Resolved

thanks

Also available in: Atom PDF