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

Captive Portal with AD - LDAP authenticates without a password !!,

Scheduled Pinned Locked Moved Captive Portal
28 Posts 8 Posters 3.7k 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.
  • D
    dimoz @brinch
    last edited by Nov 7, 2019, 2:38 PM

    @brinch, I've folloved the adjustment in the /var/etc/captiveportal_wifi_myportal.html proposed by @vicentezago.
    For now, It solved (or bypassed ;-) ) the problem

    B 1 Reply Last reply Nov 7, 2019, 2:43 PM Reply Quote 1
    • B
      brinch @dimoz
      last edited by Nov 7, 2019, 2:43 PM

      @dimoz
      Thanks, i did the same trick.
      As we dont use blank password on our domain it's fine

      F 1 Reply Last reply Nov 7, 2019, 3:04 PM Reply Quote 0
      • F
        free4 Rebel Alliance @brinch
        last edited by Nov 7, 2019, 3:04 PM

        @brinch I think it's too late now...but could you try to make a packet capture on the interface where your AD is, when you are authenticating with an empty password? then could you give me the packet capture by private message ?

        I am very surprised by this kind of LDAP bug. I would like to check if it entirely related to your AD configuration or is pfsense part of the issue

        (Warning / big Disclaimer : this packet capture will contain username/password of the account used in pfSense for binding to the AD, and the username that you are trying to login with on the captive portal. Depending on how critical this data is, you could change passwords or use temporary usernames)

        B 1 Reply Last reply Nov 8, 2019, 7:21 AM Reply Quote 0
        • B
          brinch @free4
          last edited by Nov 8, 2019, 7:21 AM

          @free4 Ok i send you the capture file

          F 1 Reply Last reply Nov 8, 2019, 11:12 PM Reply Quote 0
          • F
            free4 Rebel Alliance @brinch
            last edited by Nov 8, 2019, 11:12 PM

            Well, I have some news,

            I could analyze the pcap @brinch sent me. I can confirm that the problem comes from his Active Directory server which successfully bind when user provides an empty password.

            I did some research, and apparently it seems to be a microsoft "feature" called unauthenticated bind : https://blog.lithnet.io/2017/01/ad-lds-and-ldap-unauthenticated-binds.html

            Unlike anonymous bind, unauthenticated binds are enabled by default in Microsft Active directory.

            It is also apparently impossible to disable unauthenticated binds on Microsoft AD : https://serverfault.com/questions/947428/how-to-disable-unauthenticated-binds-in-active-directory2016

            I wasn't aware of this controversy. @jimp perhaps we should add an option for forbidding unauthenticated binds?

            1 Reply Last reply Reply Quote 0
            • F
              free4 Rebel Alliance
              last edited by free4 Nov 16, 2019, 8:59 PM Nov 16, 2019, 8:59 PM

              Hello,

              For information, I made a patch for it: https://github.com/pfsense/pfsense/pull/4116

              @brinch @dimoz @olakara could you please try this patch and tell me if it is working for you ?

              The process :

              1. Install the patch package
              2. Go to the menu "system-> Patch".
              3. Create a new patch. In "URL/Commit ID", enter "https://github.com/pfsense/pfsense/pull/4116.diff". Leave other fields to default values/empty, and click submit
              4. Go to your LDAP server settings. A new field (dis)allowing unauthenticated LDAP binds will appear.

              Regards,
              Augustin

              D 1 Reply Last reply Jan 24, 2020, 10:13 AM Reply Quote 0
              • D
                dimoz
                last edited by Nov 20, 2019, 7:52 AM

                Thankyou @free4
                Give me some days to implement a laboratory clone because I have all the firewalls in production environment.

                1 Reply Last reply Reply Quote 0
                • D
                  dimoz @free4
                  last edited by Jan 24, 2020, 10:13 AM

                  @free4
                  Hi Augustin.
                  I apologize for the delay but I have been quite busy.
                  I created a test firewall and tried to apply the patch, but in testing (before installation) it gives me these errors.
                  PfSense 2.4.4p3

                  Patch Test Output apply
                  /usr/bin/patch --directory=/ -t -p2 -i /var/patches/5e2ab70eea69c.patch --check --forward --ignore-whitespace

                  Hmm... Looks like a unified diff to me...
                  The text leading up to this was:

                  |diff --git a/src/etc/inc/auth.inc b/src/etc/inc/auth.inc
                  |index 4139ad22b46..35e9e46ddae 100644
                  |--- a/src/etc/inc/auth.inc

                  +++ b/src/etc/inc/auth.inc
                  Patching file etc/inc/auth.inc using Plan A...
                  Hunk #1 succeeded at 1370 (offset -1 lines).
                  Hunk #2 failed at 1963.
                  1 out of 2 hunks failed while patching etc/inc/auth.inc
                  Hmm... The next patch looks like a unified diff to me...
                  The text leading up to this was:

                  |diff --git a/src/etc/inc/ipsec.auth-user.php b/src/etc/inc/ipsec.auth-user.php
                  |index 71ed2b6bcbc..cfd48cfc24d 100755
                  |--- a/src/etc/inc/ipsec.auth-user.php

                  +++ b/src/etc/inc/ipsec.auth-user.php
                  Patching file etc/inc/ipsec.auth-user.php using Plan A...
                  Hunk #1 succeeded at 49 (offset -2 lines).
                  Hmm... The next patch looks like a unified diff to me...
                  The text leading up to this was:

                  |diff --git a/src/etc/inc/openvpn.auth-user.php b/src/etc/inc/openvpn.auth-user.php
                  |index 6bb059a458e..abd9accf92a 100644
                  |--- a/src/etc/inc/openvpn.auth-user.php

                  +++ b/src/etc/inc/openvpn.auth-user.php
                  Patching file etc/inc/openvpn.auth-user.php using Plan A...
                  Hunk #1 succeeded at 51 (offset -2 lines).
                  Hmm... The next patch looks like a unified diff to me...
                  The text leading up to this was:

                  |diff --git a/src/usr/local/www/diag_authentication.php b/src/usr/local/www/diag_authentication.php
                  |index 6bd0789441d..5ef3db69553 100644
                  |--- a/src/usr/local/www/diag_authentication.php

                  +++ b/src/usr/local/www/diag_authentication.php
                  Patching file usr/local/www/diag_authentication.php using Plan A...
                  Hunk #1 succeeded at 38 (offset -2 lines).
                  Hmm... The next patch looks like a unified diff to me...
                  The text leading up to this was:

                  |diff --git a/src/usr/local/www/guiconfig.inc b/src/usr/local/www/guiconfig.inc
                  |index b3b21dfdfee..00cb98b0e53 100644
                  |--- a/src/usr/local/www/guiconfig.inc

                  +++ b/src/usr/local/www/guiconfig.inc
                  Patching file usr/local/www/guiconfig.inc using Plan A...
                  Hunk #1 succeeded at 142 (offset -2 lines).
                  Hmm... The next patch looks like a unified diff to me...
                  The text leading up to this was:

                  |diff --git a/src/usr/local/www/system_authservers.php b/src/usr/local/www/system_authservers.php
                  |index 21d107ec03a..b68283f5ab6 100644
                  |--- a/src/usr/local/www/system_authservers.php

                  +++ b/src/usr/local/www/system_authservers.php
                  Patching file usr/local/www/system_authservers.php using Plan A...
                  Hunk #1 succeeded at 159 (offset -2 lines).
                  Hunk #2 succeeded at 332 (offset -5 lines).
                  Hunk #3 succeeded at 765 (offset -6 lines).
                  Hunk #4 succeeded at 989 (offset -5 lines).
                  Hmm... The next patch looks like a unified diff to me...
                  The text leading up to this was:

                  |diff --git a/src/usr/local/www/wizards/openvpn_wizard.inc b/src/usr/local/www/wizards/openvpn_wizard.inc
                  |index 5223ec8bad6..0a20b06f908 100644
                  |--- a/src/usr/local/www/wizards/openvpn_wizard.inc

                  +++ b/src/usr/local/www/wizards/openvpn_wizard.inc
                  Patching file usr/local/www/wizards/openvpn_wizard.inc using Plan A...
                  Hunk #1 succeeded at 479 (offset -14 lines).
                  Hmm... The next patch looks like a unified diff to me...
                  The text leading up to this was:

                  |diff --git a/src/usr/local/www/wizards/openvpn_wizard.xml b/src/usr/local/www/wizards/openvpn_wizard.xml
                  |index e5d154a4693..30649a9cd2c 100644
                  |--- a/src/usr/local/www/wizards/openvpn_wizard.xml

                  +++ b/src/usr/local/www/wizards/openvpn_wizard.xml
                  Patching file usr/local/www/wizards/openvpn_wizard.xml using Plan A...
                  Hunk #1 succeeded at 302 (offset -2 lines).
                  done
                  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