Project

General

Profile

Actions

Feature #5112

closed

LDAP support for Captive Portal

Added by Robert Sander over 8 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Category:
Captive Portal
Target version:
Start date:
09/07/2015
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:

Description

The captive portal currently only supports the local user database or RADIUS.

RADIUS needs clear text passwords on the RADIUS server to do CHAP or MSCHAPv2.

It would be very convenient if the captive portal could also use an (already configured) LDAP server the same way as the OpenVPN service does for example.

Actions #1

Updated by Felix Wolfsteller over 8 years ago

I also was expecting that this would work out of the box.

For me the setup is as follows (and I think it resembles a "typical" use case):

  • pfSense appliance with only one local admin user.
  • As further User authentication server an openldap running on a different host.
  • Furthermore, groups setup in openLDAP and pfsense, respectively. The relevant group has only Captive Portal Login privileges.

As Diagnostics->Authentication showed that my openldap test account is member of the "correct" group I assumed that after enabling CP everything should work fine (although I was shortly puzzled by the word "local" in the CP authentication settings). And of course ticking the option whether group memberships should be checked or not did not have any effect.

Btw, this issue was also raised at the forums over at https://forum.pfsense.org/index.php?topic=87869.0 . It quickly mentions in which order the authentication sources should be checked (currently User Manager->Servers cannot be ordered).

Actions #2

Updated by Felix Wolfsteller over 8 years ago

After browsing the codebase a bit I am surprised how much understanding I gained in a short amount of time.

I think not much is missing:

A rough implementation sketch that preserves backwards compatibility:

  1. On Services:Captive portal: <zone> page
    "Authentication" Section:
    • Add another radiobutton
      o Local User Manager and all <a href=".../system_authservers.php">configured additional Servers</a>/ Vouchers
      o Allow only... #checkbox like in other entry
    • Pass this value (say "local_plus") down to further procesing if ticked (I dont know php and the rest of the codebase)
  1. Copy https://github.com/pfsense/pfsense/blob/master/src/usr/local/captiveportal/index.php#L237-L254
    and modify cpcfg['auth_method'] "local" to "local_plus" or whatever name from 1).
    • After the "//check against local user manager"-block iterate over the ldap-backends and call
      $loginok = ldap_backend($_POST['auth_user'], $_POST['auth_pass']);
    • Handle the result accordingly for each. Early stop at a success if privilege check passes. Otherwise set $errormsg, or accumulate them along the way. Decorate with log-entries at will.

It seems a rather trivial change to me (at least code-wise). I'd be super happy to patch my system by actually changing https://github.com/pfsense/pfsense/blob/master/src/usr/local/captiveportal/index.php#L240 (s/local/ldap), but unfortunately ldap_backend takes an additional parameter, the ldap-backend configuration. If somebody can tell me how to access the first one available to the system and confirm that this will not break updates, I would hack my pfSense instance immidiatly ...

Actions #3

Updated by Felix Wolfsteller over 8 years ago

Felix Wolfsteller wrote:

  1. Copy https://github.com/pfsense/pfsense/blob/master/src/usr/local/captiveportal/index.php#L237-L254
    and modify cpcfg['auth_method'] "local" to "local_plus" or whatever name from 1).
    • After the "//check against local user manager"-block iterate over the ldap-backends and call
      [...]
    • Handle the result accordingly for each. Early stop at a success if privilege check passes. Otherwise set $errormsg, or accumulate them along the way. Decorate with log-entries at will.
$authcfg = auth_get_authserver($config['system']['webgui']['authmode']);
$loginok = authenticate_user($_POST['auth_user'], $_POST['auth_pass'], $authcfg, NULL);

might do the job as well.
Actions #4

Updated by Felix Wolfsteller over 8 years ago

With some help from PiBa-NL via IRC I can confirm that the hackish approach works fine.

$authcfg = auth_get_authserver("YOUR LDAP BACKEND NAME");
$_attributes = array();
$loginok = authenticate_user($_POST['auth_user'], $_POST['auth_pass'], $authcfg, $_attributes);

I then uncommented the privilege checking. I hope I find the time to layout changes in a github PR and would like some guidance on how the new configuration options should be structured. It can get complicated if one wishes, but there I will not help much.

Actions #5

Updated by Filippo Sorbellini over 7 years ago

I'm interested to this feature. It will be officially implemented?

Actions #6

Updated by Felix Wolfsteller over 6 years ago

Any chance an implementation as outlined above would make it into upstream? Would be happy to give the implementation a try, but time-to-try is limited.

Actions #7

Updated by Oscar Francia over 6 years ago

https://github.com/pfsense/pfsense/pull/3117 implementation works on 2.4 BETA 09 Aug 2017

Actions #9

Updated by Renato Botelho over 5 years ago

  • Status changed from New to In Progress
  • Assignee set to Renato Botelho
  • Target version set to 2.4.4
Actions #10

Updated by Renato Botelho over 5 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100

PR merged

Actions #11

Updated by A FL over 5 years ago

I confirm that LDAP is working correctly now
This issue can be marked as resolved

Actions #12

Updated by Jim Pingle over 5 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF