eDirectory password with german umlaut

[Florian Racky]

Hi,

we use eDirectory to authenticate our intranet users. This works fine for most of the users. But some of them use german umlauts (ä, ö, ü...) in their passwords and I am not able to authenticate these. eDirectory returns "invalid credentials".

I tried to utf-8 and unicode-encode the passwords before binding but authentication is still not working. We use PHP compiled with the openldap client lib 2.1.12 (?) on a linux box.

Does anyone know the correct encoding to use or does anyone know if this is a problem of the openldap client lib?

Flo

[Peter Kuo]

Florian,

Hasn't tried myself, but have you tried base64 encoding instead?

Peter
Novell Product Support Forum
'NDS Rules!'

[Florian Racky]

Hi Peter,

> Hasn't tried myself, but have you tried base64 encoding instead?

This might be a way but base64 encoding changes every character in the
password string.

myPassword becomes bXlQYXNzd29yZA==
myPasswörd becomes bXlQYXNzd/ZyZA==
(if not displayed correctly: the second one contains "oumlaut" instead
of "o")

The users using 7-bit ASCII passwords can successfully authenticate. So
if I am going to use base64 encoded passwords instead I expect that
these users will no longer be able to login. There must be a way to tell
eDirectory while transmitting the login data that the password is a base
64 encoded one. Something like:

(base64)bXlQYXNzd/ZyZA==

I already tried utf-8 encoding, which does not change 7-Bit Strings:

myPassword is still myPassword
myPasswörd becomes myPasswƶrd
(if not displayed correctly: the second one contains "oumlaut" instead
of "o", the utf-8 encoded string has two "weird" characters between "w"
and "d")

=> utf-8 would work for 7-Bit and "special character" logins. But
eDirectory still refuses to authenticate with utf-8 encoded passwords.

Flo

[Onno Molenkamp]

Florian Racky wrote:
> myPassword becomes bXlQYXNzd29yZA==
> myPasswörd becomes bXlQYXNzd/ZyZA==

You will always have use UTF-8 encoding. So myPasswörd will become
bXlQYXNzd8O2cmQ=.

> The users using 7-bit ASCII passwords can successfully authenticate. So
> if I am going to use base64 encoded passwords instead I expect that
> these users will no longer be able to login. There must be a way to tell
> eDirectory while transmitting the login data that the password is a base
> 64 encoded one. Something like:

In LDIF a base64 encoded string is marked by using two colons instead of
one.

So

userpassword: myPassword

and

userpassword:: bXlQYXNzd29yZA==

are equal.

Onno

[Onno Molenkamp]

About authenticating: using just UTF-8 should work. It does work from
perl (Net::LDAP), Java (Novell JLDAP) and ldapsearch. (OpenLDAP)

I don't have PHP to try this, but since it uses the same libraries I
would expect the same. Does authenticating with Client32 work?

Onno

[Florian Racky]

Hi,

> About authenticating: using just UTF-8 should work. It does work from
> perl (Net::LDAP), Java (Novell JLDAP) and ldapsearch. (OpenLDAP)

And I think it should work for with PHP. Perhaps it is a problem with
the ldap client lib used to compile PHP. I even tried to write the
password to a file, convert it to utf-8 using iconv and then use it with
an ldapsearch-command. Same result. The LDAP server tells me that I have
"invalid credentials".

> would expect the same. Does authenticating with Client32 work?

The users can successfully authenticate themselves using the Novell
client on their workstations.

Thanks for your help so far.

Flo

[Florian Racky]

Hi Onno,

> You will always have use UTF-8 encoding. So myPasswörd will become
> bXlQYXNzd8O2cmQ=.

Did I get you right?

1. base64 encode the password: myPasswörd -> bXlQYXNzd/ZyZA==
2. utf-8 encode the base64 string: bXlQYXNzd/ZyZA== -> bXlQYXNzd/ZyZA==

Step 2 will leave the base64-String unchanged because it does not change
7 Bit characters. So my result is different from yours. What did I do wrong?

> In LDIF a base64 encoded string is marked by using two colons
> instead of

I am not trying to add an entry to the directory but trying to bind
using LDAP...

Flo