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

    [solved] 2.4 broke LDAP against Mac OS Server

    Scheduled Pinned Locked Moved General pfSense Questions
    14 Posts 4 Posters 1.9k 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.
    • S
      SpaceBass
      last edited by

      hello friends!

      Over the weekend I upgraded all my boxes to 2.4 and am enjoying the many improvements.

      However, I've run into one significant snag. In my set up, authenticating against LDAP, specifically Mac OS 10.11 servers, seems to be broken.

      For 2.3, this guide was a life saver:
      https://www.reddit.com/r/PFSENSE/comments/4u3bzu/authentication_servers_os_x_open_directory_working/

      That configuration worked perfectly for me for authing in OpenVPN and elsewhere in PFsense. in 2.4, something seems to have changed.

      If I leave SSL enabled, I get the following in the logs:

      php-fpm	86214	/system_authservers.php: ERROR! ldap_get_user_ous() could not bind anonymously to server .
      

      If I disable SSL I get nothing in the logs, but the authentication still fails.

      If I re-enable SSL and add a bind auth name and password, it simple says:

      could not bind to server
      

      The SSL certificates on the servers are commercially signed and valid and I'm using FQDNs in the authentication set up. I have confirmed that I can ping the hostnames from the PF console.

      In the PF console, this returns every CN on the LDAP server successfully:

      ldapsearch -H ldaps://sever.foo.bar:636 -b "DC=server,DC=foo,DC=bar"
      

      where server.foo.bar is actually my LDAP server's FQDN

      Anyone have any troubleshooting tips?

      1 Reply Last reply Reply Quote 0
      • T
        tim.mcmanus
        last edited by

        What do the logs on the OS X Server show?  When pfSense is making its queries, are they being received?  Do they fail?

        1 Reply Last reply Reply Quote 0
        • S
          SpaceBass
          last edited by

          before I post the MacOS logs, when I logged back into PF tonight, this little crash report was waiting for me:

          amd64
          11.0-RELEASE-p12
          FreeBSD 11.0-RELEASE-p12 #8 1032370b1f4(RELENG_2_4_0): Wed Aug 23 00:42:26 CDT 2017     root@buildbot2.netgate.com:/builder/factory-240/tmp/obj/builder/factory-240/tmp/FreeBSD-src/sys/pfSense
          
          Crash report details:
          
          PHP Errors:
          [27-Aug-2017 21:55:08 Etc/UTC] PHP Warning:  ldap_start_tls(): Unable to start TLS: Connect error in /etc/inc/auth.inc on line 1074
          [27-Aug-2017 21:55:08 Etc/UTC] PHP Stack trace:
          [27-Aug-2017 21:55:08 Etc/UTC] PHP   1\. {main}() /usr/local/www/system_authservers.php:0
          [27-Aug-2017 21:55:08 Etc/UTC] PHP   2\. ldap_get_user_ous() /usr/local/www/system_authservers.php:52
          [27-Aug-2017 21:55:08 Etc/UTC] PHP   3\. ldap_start_tls() /etc/inc/auth.inc:1074
          [27-Aug-2017 21:55:20 Etc/UTC] PHP Warning:  ldap_start_tls(): Unable to start TLS: Connect error in /etc/inc/auth.inc on line 1074
          [27-Aug-2017 21:55:20 Etc/UTC] PHP Stack trace:
          [27-Aug-2017 21:55:20 Etc/UTC] PHP   1\. {main}() /usr/local/www/system_authservers.php:0
          [27-Aug-2017 21:55:20 Etc/UTC] PHP   2\. ldap_get_user_ous() /usr/local/www/system_authservers.php:52
          [27-Aug-2017 21:55:20 Etc/UTC] PHP   3\. ldap_start_tls() /etc/inc/auth.inc:1074
          
          No FreeBSD crash data found.
          
          
          1 Reply Last reply Reply Quote 0
          • S
            SpaceBass
            last edited by

            @tim.mcmanus:

            What do the logs on the OS X Server show?  When pfSense is making its queries, are they being received?  Do they fail?

            nada…zip ... they don't show a thing :/
            if I do a tcpdump port 636 I can see the traffic hitting the Mac OS box.

            but the plot thickens.

            If I change to STARTLS I get the following "error"? at the top of the PF page:

            Warning: ldap_start_tls(): Unable to start TLS: Connect error in /etc/inc/auth.inc on line 1342 Call Stack: 0.0001 233640 1\. {main}() /usr/local/www/diag_authentication.php:0 0.0580 1633400 2\. authenticate_user() /usr/local/www/diag_authentication.php:47 0.0581 1633640 3\. ldap_backed() /etc/inc/auth.inc:1748 0.0593 1635256 4\. ldap_start_tls() /etc/inc/auth.inc:1342
            

            Authentication still fails.

            If I change to TCP (no encryption) it works. (Which I share was different than yesterday…but maybe the Hawthorne effect with tcpdump is real :)  ... needless to say, I'd prefer not to drop SSL.

            1 Reply Last reply Reply Quote 0
            • DerelictD
              Derelict LAYER 8 Netgate
              last edited by

              Is your LDAP server configured for TCP - Standard (on port 389), TCP - STARTTLS (on port 389), or SSL (on port 636)??

              Chattanooga, Tennessee, USA
              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
              Do Not Chat For Help! NO_WAN_EGRESS(TM)

              1 Reply Last reply Reply Quote 0
              • S
                SpaceBass
                last edited by

                @Derelict:

                Is your LDAP server configured for TCP - Standard (on port 389), TCP - STARTTLS (on port 389), or SSL (on port 636)??

                it responds on both TCP and SSL. I prefer SSL obviously and it worked with SSL prior to the upgrade from 2.3.x to 2.4

                and on multiple Ubuntu installs, this line in ldap.conf is sufficient (along with the base)

                uri ldaps://server.foo.bar
                ```with the server's commercial cert I don't even have to load the CA on the ubuntu boxes.
                1 Reply Last reply Reply Quote 0
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by

                  OK. But that is not what I asked. I asked how you had it set.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                  1 Reply Last reply Reply Quote 0
                  • S
                    SpaceBass
                    last edited by

                    @Derelict:

                    OK. But that is not what I asked. I asked how you had it set.

                    Sorry, perhaps I didn't understand the question correctly. My bad!

                    The server itself is set to respond to TCP - Standard (on port 389) and SSL (on port 636)

                    In PF I have tried:

                    • TCP - Standard (on port 389) Worked once - nice again

                    • TCP - STARTTLS (on port 389) - does not work

                    [iii] SSL (on port 636) - does not work [/iii]

                    1 Reply Last reply Reply Quote 0
                    • DerelictD
                      Derelict LAYER 8 Netgate
                      last edited by

                      And standard works and SSL does not?

                      Chattanooga, Tennessee, USA
                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                      1 Reply Last reply Reply Quote 0
                      • S
                        SpaceBass
                        last edited by

                        @Derelict:

                        And standard works and SSL does not?

                        Standard worked once. Once I try SSL and the error gets thrown, standard doesn't work again until I reboot PF or wait for something (?) to time out… EG it worked once today but not since.

                        One other note on my end - above I said it's Mac OS 10.11 which is incorrect. I'm running 10.12.5

                        1 Reply Last reply Reply Quote 0
                        • DerelictD
                          Derelict LAYER 8 Netgate
                          last edited by

                          I am looking at this. I don't know if it is OS X Server or SSL/STARTTLS LDAP in general.

                          I do not see what you see.

                          Standard always works.

                          SSL fails with Authentication Failed

                          STARTTLS fails with Authentication failed and also throws this:

                          Warning: ldap_start_tls(): Unable to start TLS: Connect error in /etc/inc/auth.inc on line 1342 Call Stack: 0.0000 233808 1. {main}() /usr/local/www/diag_authentication.php:0 0.0244 1622264 2. authenticate_user() /usr/local/www/diag_authentication.php:47 0.0244 1622504 3. ldap_backed() /etc/inc/auth.inc:1748 0.0247 1624128 4. ldap_start_tls() /etc/inc/auth.inc:1342

                          I can change the Transport at will and the behavior is the same. No reboots or anything like that necessary.

                          There is an issue with certificate validation it seems. Perhaps something changed in openldap. Not sure yet.

                          2.4.0-RC (amd64)
                          built on Mon Aug 28 11:05:02 CDT 2017
                          FreeBSD 11.0-RELEASE-p12

                          GeoTrust RapidSSL Certificate

                          macOS Server 10.11.6

                          ETA: According to packet captures both SSL and STARTTLS are failing with TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unknown CA)

                          Chattanooga, Tennessee, USA
                          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                          Do Not Chat For Help! NO_WAN_EGRESS(TM)

                          1 Reply Last reply Reply Quote 0
                          • T
                            tim.mcmanus
                            last edited by

                            You have to look also at the server version, 5.3 or 5.4, depending on the Mac OS version.  There are also CLI commands to increase logging.  man serveradmin is a good place to start.

                            1 Reply Last reply Reply Quote 0
                            • S
                              SpaceBass
                              last edited by

                              Hey friends!
                              Thanks to this forum and this Reddit thread: https://www.reddit.com/r/PFSENSE/comments/6wm2m1/24_broke_ldap_auth_against_mac_os_servers/
                              i've found success!

                              It turns out —not sure why this wasn't the case in 2.3.x —that the entire chain is needed for commercial certs to work.

                              I had tried concatenating them by hand and exporting them from Keychain Access but it didn't work.

                              This command, on the other hand, generated a complete chain that works for commercial certs on macOS

                              openssl s_client -host <fqdn> -port 443 -prexit -showcerts</fqdn>
                              

                              This, of course, assumes ones web server uses the same cert and chain as the LDAP server, but in most OS X Server deployments, that's probably the case. If not, it'd be trivial to set up a web server using the LDAP cert and pull it this way. One might also simply change the port (although I didn't try it) to 636.

                              That spits out an entire chain of certs in the right order (which apparently matters) which one can past into a CA in PF's CA screen.

                              Hope this helps someone else!

                              Thanks everyone for the troubleshooting tips and help to get this far!

                              1 Reply Last reply Reply Quote 0
                              • jimpJ
                                jimp Rebel Alliance Developer Netgate
                                last edited by

                                I pushed a fix yesterday to make it build the entire chain automatically.

                                Assuming you have all of the CA certs and intermediates imported, you can select the bottom intermediate as the LDAP CA and it will figure out the rest.

                                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
                                • First post
                                  Last post
                                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.