LDAP authorization Umlaut bug
-
And it works ok if you use a password without special characters? Or no?
-
yes. that works just fine.
-
In the LDAP server settings, tick the box to UTF-8 encode the LDAP query (it's off by default)
-
Sorry, I forgot to mention that in my first post.
The UTF-8 Encoding is checked since the beginning of my tests.
-
DIRTY FIX!
I still can't browse Authentication Containers (probably another Problem with authentication), error message "Could not connect to the LDAP server. Please check your LDAP configuration."
After a lot of Debugging, I have found that I can use the Authentication for OpenVPN anyway, BUT:
I commented out the line that encodes the user Password from the VPN Client to utf8.
/* Now lets bind as the user we found */
#$passwd = isset($authcfg['ldap_utf8']) ? utf8_encode($passwd) : $passwd;I don't know if that is a valid solution for all Clients, it works for me.
Sidenote
I had to use the following Extended query to get the Group Membership working with a Windows Server 2008:
memberOf:1.2.840.113556.1.4.1941:=CN=group,OU=business,DC=asdf,DC=local -
Just to keep things up to date…
I'm not sure since what update things changed for me.
At the moment I connect to Windows AD with utf8 encoding OFF, but editing auth.inc line 721 to putenv('LDAPTLS_REQCERT=never');For some reason things are always messed up after an update of pfsense. Is it possible that something goes wrong with the password stored in the openvpn settings page? I was debugging for an hour now just to find that re-entering the password in the settings did the trick.
-
There's no need to do any such thing, import the the AD CA certificate on pfSense.
-
I imported the CA, even made sure that the Name was the CN Name in the certificate. (Used a DNS Forward to trick pfsense into resolving the name to the correct server).
-
(Used a DNS Forward to trick pfsense into resolving the name to the correct server).
What??? Why would any such hack be needed? You are doing something badly wrong there.
-
The resolving trick was necessary because Windows SBS sets up a CA automatically and gives it a name that is not the FQDN.
But I started all over yesterday and set up the ldap from scratch. And actually got it to work without any hacking, trickery, etc.
I imported the CA certificate, created a dns entry for the CN (this time on my internal dns server and not inside pfsense) and have the encoding checkbox unchecked now. Re-entered bind username and password.
And now things are working.
Thanks to all the people helping me along.