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



  • I have pfsense 2.4.4._1 Captive portal with LDAP ( Windows 2008 AD Server ). AD server configured @ User Manager - Authentication server and it works fine while testing at Diagnostics - Authentication. Also I can authenticate Captive portal user without any issue. But the CP users can authenticate only entering the user name ! ( without entering a password ). How to fix the issue ?

    regards,


  • Rebel Alliance

    @olakara said in Captive Portal Authentication with AD - LDAP authenticates only with user name ( without password ):

    I have pfsense 2.4.4._1 Captive portal with LDAP ( Windows 2008 AD Server ). AD server configured @ User Manager - Authentication server and it works fine while testing at Diagnostics - Authentication. Also I can authenticate Captive portal user without any issue. But the CP users can authenticate only entering the user name ! ( without entering a password ). How to fix the issue ?

    regards,

    Create a custom captive portal login page.

    Inside this custom page, include an hidden input :

    <input type="hidden" name="auth_pass" value="" />
    

    This should fix your issue



  • @free4

    didnt work :(,

    I'm using modified default login page with user, password and voucher code. unfortunately the page allows the user to authenticate with empty password ...

    	  <form name="login_form" method="post" action="http://192.168.11.1:8002/index.php?zone=srmg">		<input type="text" name="auth_user" placeholder="User" id="auth_user">
    		<input type="password" name="auth_pass" placeholder="Password" id="auth_pass">				<br  /><br  />
    				<input name="auth_voucher" type="text" placeholder="Voucher Code">
    				<input type="hidden" name="auth_pass" value="" />
    		<input name="redirurl" type="hidden" value="http://detectportal.firefox.com/success.txt">
    		<input type="submit" name="accept" class="login login-submit" value="Login" id="login" >
    	  </form>
    

    0_1546956919266_WhatsApp Image 2019-01-08 at 4.36.59 PM.jpeg



  • Check your 'html' code : you have now twice a reference to :

    <input type="password" name="auth_pass" placeholder="Password" id="auth_pass">
    and
    <input type="hidden" name="auth_pass" value="" />

    This one
    <input type="hidden" name="auth_pass" value="" />
    makes a hidden empty password.

    You should remove the other one, just above.



  • @gertjan

    seems my post was not clear to you. I need the CP users to authenticate with username + password. Now a user can login in 2 methods as follows:

    1. username and blank password. ( this not acceptable )
    2. username and password ( This is okay)
      If i make the change as per your suggssion, the password field will disappear...
    <input type="text" name="auth_user" placeholder="User" id="auth_user">
    		<input type="hidden" name="auth_pass" value="" 				<br  /><br  />
    				<input name="auth_voucher" type="text" placeholder="Voucher Code">
    


  • Ok, then I don't understand.

    If you have a users like 12345678 and a password, then users can't login without password that belongs to that user.
    Are you saying that "12345678" is enough to have access ?


  • LAYER 8 Netgate

    Duplicate the "log in with no password" behavior with the default login page.



  • @gertjan yes, 12345678 is enough to have access, or 12345678+ password... both will work..



  • @derelict

    Jan 9 10:27:46 logportalauth 20913 Zone: wifitest - ACCEPT: olakara, 00:1f:f3:be:3c:xx, 192.168.11.102


  • Rebel Alliance Developer Netgate

    I can't replicate the problem here. Set to check against LDAP, I get a login failure if I do not provide a password.

    0_1547044728238_Selection_119.jpg



  • @jimp for me this works only with local database, LDAP still allow access without password

    0_1547109907178_pf1.png


  • Rebel Alliance Developer Netgate

    Then it must be your AD server returning a successful auth message. The LDAP client on pfSense is working properly as far as I can tell.

    Run a packet capture of the LDAP exchange and run it through Wireshark, see what the AD server is returning to you.



  • @jimp said in Captive Portal with AD - LDAP authenticates without a password !!,:

    see what the AD server

    Probably set up as a " Yes-Ok-Proceed" server ...

    Btw : AD Server log should tel you what happens.



  • Hello guys. All right?

    Until I found a definitive solution, I made an adjustment in the /var/etc/captiveportal_wifi_myportal.html file to not continue if the password field is empty.

    Before
    <input type = "password" name = "auth_pass" placeholder = "Password" id = "auth_pass">

    After
    <input type = "password" name = "auth_pass" placeholder = "Password" id = "auth_pass" required>

    That's it for now.

    Thank you.



  • Hi.
    I have 3 firewall PfSense 2.4.4-RELEASE-p2 with a LDAP Authentication Servers (Windows Server 2008 R2 Forest) and i can confirm the same behavior reported by vicentezago.
    Captive Portal accept authentication with a blank password (to be correct, the authentication is successful with the blank password only if the user is in the required AD Groups filtered by an extended query set in the ldap authentication server).
    The strange things is that the "Authentication Tool" in Diagnostic Menu don't accept the blank password.

    For now I have edited the CP page as vcentezago.

    I found a post in the OPNSense Forum that say that the bug is resolved with the 741082208 patch. I post the link.

    https://forum.opnsense.org/index.php?topic=4605.0

    Is it possible to implement same patch in PfSense?


  • Rebel Alliance Developer Netgate

    Their code just prevents attempting to login with a blank password. While OK, that seems like a bad workaround. If your LDAP server is allowing someone to login with a blank password, you should fix the server instead.



  • Ok, but I don't understand where is the problem in my Windows server.
    All users that I tested have a NOT blank password in Active Directory (Windows client PCs and the Authentication test in Diagnostic confirm this because return error if I try to authenticate with blank password ("Simple! It is the wrong password! :-))).
    Why CP accept this username/password_blank pairing?

    Thanks


  • Rebel Alliance Developer Netgate

    CP is not deciding to pass it with a blank password. It passes the authentication request off to your AD server. CP is only accepting it because AD returns a response that says the authentication was successful.

    You need to figure out why that is and change the server so it doesn't happen. Anonymous binds are one potential source of problems here, but it's definitely something on your AD server that needs fixed.

    The problem is that even if CP or pfSense in general is patched to stop this, that does nothing to prevent other services that also authenticate against your AD structure from also performing the same kind of binds and succeeding without a password. The problem needs solved at the source, you can't patch away this kind of security problem.



  • Thank You.
    You give me a great hand to direct me in the right way.
    I think that the problem is that the Base DN or the Search Base DN (I will try) are set as the rootDSE of the domain for which anonymous binds should be allowed by design.
    Thank You very much



  • @dimoz
    Hi dimoz
    I have that exact same issue.
    Did it fix something to change the search base OU?



  • @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



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


  • Rebel Alliance

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



  • @free4 Ok i send you the capture file


  • Rebel Alliance

    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?


  • Rebel Alliance

    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



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



  • @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


Log in to reply