Syspass: German umlauts don't work correctly

[davidpsc]

Hi,

after upgrading from sysPass 1.1.2.24 to 1.2.0.13 we have an issue with accounts where the password containes the characters "Ä", "Ü" or "Ö" (note that the characters are uppercase). In the old sysPass version the password showed up normally but now after the update it just shows "null". So it seems to fail decoding it. We tried to change the password to the same that it should have been in the new version but it stays at "null".
When we try to enter the same password with lowercase umlauts the decoding works but it shows wrong characters (charset/encoding issue?). So for example "zuizue7632673äöüöä" is shown as "zuizue7632673äöüöä" which is not usable... Passwords with no umlauts work fine.

Please take a look at the issue and try it yourself with the German umlauts. Please note that there is a difference between using uppercase umlauts (decoding fails, it shows "null") and lowercase umlauts (decoding works but doesn't display right).

Thanks!

Edit: I forgot to add some (maybe useful) information about our environment: we have sysPass running on Windows (IIS 8.5 + PHP 5.3.28) with MySQL 5.6.23. In our database we use the collation utf8_general_ci for all tables.

[nuxsmin]

I've tested it at the demo site (demo.syspass.org) and it worked as expected. Please, take a look to the demo by searching "german".

[davidpsc]

You're right, it works as expected in the demo. Was there anything changed regarding this since 1.2.0.13?
Can the collation be an issue? What collation do you use for the demo database? And I guess the demo is not running on Windows right? What PHP version is used (maybe we need to update PHP)?
It's a strange issue because our environment didn't change with the new version. It is all the same as it was at version 1.1.2.24 where it worked as expected...

This is kind of an important thing for us to have umlauts in the password. And it also saves without an error so it is not good to have it successfully saved but cannot use the password later on...

[nuxsmin]

The demo site is hosted in a linux environment that runs PHP 5.6. The collation does not apply, because the field type is VARBINARY.

It's really weird...

[nuxsmin]

There were some paswword changes since 1.1.2.19 that changed the field type to VARBINARY, but you were in an earlier version:

https://github.com/nuxsmin/sysPass/blob/master/inc/Upgrade.class.php#L100

[davidpsc]

I've updated PHP today from 5.3 to 5.6.24 - now the passwords work as expected!
But unfortunately our LDAP login is broken (I've checked the password issue via DB user syspass), the log just says that the connection cannot be established, LDAP ERROR: (0)
What could be the cause for this issue now?

[nuxsmin]

Can you perform a LDAP test by using this gist https://gist.github.com/nuxsmin/a6b2f2701ce8b78ceadd835adc26756a ?

[nuxsmin]

Please, take a look to config parameters at top.

You can put it anywhere at the web server root and point your browser to it.

[davidpsc]

Thanks, I've uploaded the script to our webserver and changed the config accordingly.

The script returns:

## Group Filter (regex): 
Array
(
)
## Group Entries: 
Array
(
    [count] => 0
)
## User Filter: 
(memberof:1.2.840.113556.1.4.1941:=)## User Entries: 
Array
(
    [count] => 0
)

But a simple LDAP query PHP script works:

$ldap_password = '<PASS>';
$ldap_username = 'LDAP@<DOMAIN>';
$ldap_connection = ldap_connect("<FQDN OF LDAP SERVER>");
if (FALSE === $ldap_connection){
    die("connection error");
}

ldap_set_option($ldap_connection, LDAP_OPT_PROTOCOL_VERSION, 3) or die('Unable to set LDAP protocol version');
ldap_set_option($ldap_connection, LDAP_OPT_REFERRALS, 0);

if(ldap_bind($ldap_connection, $ldap_username, $ldap_password) === true){
    $ldap_base_dn = 'OU=Users,DC=example,DC=com';
    $search_filter = '(&(objectCategory=person)(samaccountname=*))';
    //$search_filter = '(|(sn=*)(vorname=*))';
    $attributes = array();
    $attributes[] = 'givenname';
    $attributes[] = 'mail';
    $attributes[] = 'samaccountname';
    $attributes[] = 'sn';
    //$result = ldap_search($ldap_connection, $ldap_base_dn, $search_filter, $attributes);
    $result = ldap_search($ldap_connection, $ldap_base_dn, $search_filter);

    if($result !== false)
    {

        $entries = ldap_get_entries($ldap_connection, $result);
        for ($x=0; $x<$entries['count']; $x++){
            if (!empty($entries[$x]['givenname'][0]) &&
                 !empty($entries[$x]['mail'][0]) &&
                 !empty($entries[$x]['samaccountname'][0]) &&
                 !empty($entries[$x]['sn'][0]))

[nuxsmin]

I've just modified the gist to show errors if there.

[davidpsc]

I've also modified the test script and it works now when using:
preg_match('/^(cn=[\w\s.-]+)(,.*)?$/i', $groupName, $groupFilter);
instead of:
preg_match('/^(cn=[\w\s-]+)(,.*)?$/i', $groupName, $groupFilter);
(because our group name contains two dots) and when uncommenting the second $searchGroup line and commenting the first one, so:
$searchGroup = ldap_get_entries($ldapConn, ldap_search($ldapConn, $searchBase, $groupFilter[1], array("dn", "cn")));
works.
Now the user objects are returned. Where does the sysPass code needs to be modified to work like the test script?

[nuxsmin]

Don't worry, I'll modify the related code (at Ldap.class.php file).

Thanks so much for the feedback!

[davidpsc]

Ok, I've found the problem now: for whatever reason a space was inserted before the servername, so it was ' FQDN' instead of 'FQDN'...
I don't know where this comes from because the LDAP config wasn't changed, I just installed the new PHP version (maybe PHP 5.3 trimmed whitespaces automatically when using ldap_connect)

Now it works as expected again with sysPass 1.2.0.13!

Many thanks for your time and helping me to find the error! Really appreciate your fast support!

Please note: I've modified "auth.class.php" on line 142 to be: preg_match('/^cn=([\w\s.-]+),.*/i', $group, $groupName); (inserted dot in regex after \s) so our LDAP group "service.syspass.login" works - can you consider this change for the next release?

[nuxsmin]

Great!!..those annoying spaces :(

It'll be fixed in the next release. Thanks for the hint