• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

LDAP authorization Umlaut bug

Scheduled Pinned Locked Moved General pfSense Questions
11 Posts 4 Posters 3.4k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R
    riess82
    last edited by Jul 8, 2014, 6:30 AM Jul 3, 2014, 12:32 PM

    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.

    1 Reply Last reply Reply Quote 0
    • M
      MindfulCoyote
      last edited by Jul 3, 2014, 9:55 PM

      And it works ok if you use a password without special characters? Or no?

      Err

      –
      Erreu Gedmon

      Firewalls are hard...
      but the book makes it easier: https://portal.pfsense.org/book/

      1 Reply Last reply Reply Quote 0
      • R
        riess82
        last edited by Jul 7, 2014, 2:11 PM

        yes. that works just fine.

        1 Reply Last reply Reply Quote 0
        • J
          jimp Rebel Alliance Developer Netgate
          last edited by Jul 7, 2014, 7:30 PM

          In the LDAP server settings, tick the box to UTF-8 encode the LDAP query (it's off by default)

          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

          Need help fast? Netgate Global Support!

          Do not Chat/PM for help!

          1 Reply Last reply Reply Quote 0
          • R
            riess82
            last edited by Jul 8, 2014, 6:29 AM

            Sorry, I forgot to mention that in my first post.

            The UTF-8 Encoding is checked since the beginning of my tests.

            1 Reply Last reply Reply Quote 0
            • R
              riess82
              last edited by Jul 8, 2014, 2:41 PM

              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

              1 Reply Last reply Reply Quote 0
              • R
                riess82
                last edited by Nov 20, 2015, 9:36 PM

                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.

                1 Reply Last reply Reply Quote 0
                • D
                  doktornotor Banned
                  last edited by Nov 21, 2015, 1:30 PM

                  There's no need to do any such thing, import the the AD CA certificate on pfSense.

                  1 Reply Last reply Reply Quote 0
                  • R
                    riess82
                    last edited by Nov 21, 2015, 7:52 PM

                    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).

                    1 Reply Last reply Reply Quote 0
                    • D
                      doktornotor Banned
                      last edited by Nov 21, 2015, 10:10 PM

                      @riess82:

                      (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.

                      1 Reply Last reply Reply Quote 0
                      • R
                        riess82
                        last edited by Jan 26, 2016, 7:47 AM

                        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.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                          This community forum collects and processes your personal information.
                          consent.not_received