LDAP authorization Umlaut bug
-
Trying to set up LDAP authorization (with SSL) i came across a Problem somewhere deep inside pfsense.
I have a german Umlaut ü in the bind Password.
I open User Manager, Servers, my LDAP Server. I have disabled SSL for now, so i can sniff the traffic when i click "select" at Authentication Containers.
The error message Pops up, telling me "Could not connect to the LDAP server. Please check your LDAP configuration."
In the URL of the error window i can see the correct Password including umlaut.Sniffing the traffic on the Server side, the Umlaut got lost. I already looked into /etc/inc/auth.inc, hoping to find a place with a missing utf8_encode. Nothing obviously wrong that I could see there.
Any help is very welcome.
UPDATE: UTF-8 Encoding is checked in the Server Settings.
-
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.
