Messages

1

General Discussion / Re: Feedback regarding LDAP Implementation

« on: October 22, 2021, 08:16:46 pm »

Thanks! Aliases would be interesting. I've also proposed another option that I think would be even better here: https://github.com/opnsense/core/issues/5303

2

General Discussion / Re: Feedback regarding LDAP Implementation

« on: October 22, 2021, 06:55:29 am »

AFAIK groups are synced to the local system and for that reason, they must comply with posix and FreeBSD requirements. If you would ask me it would be something quite new that whitespace characters would be allowed here.

@mimugmail have a look at the pw utility

I think you're right. I recall seeing an old github issue where having a space in the group name would cause an error due to running a groupadd command.

What I'm thinking of proposing would be a totally separate construct, essentially just made to control permissions for LDAP users who don't have a local user copy.

3

General Discussion / Re: Feedback regarding LDAP Implementation

« on: October 21, 2021, 06:59:59 am »

What when you want to use your group also for connecting OpenVPN, you cant create a certificate for export without a local user. Everyone has different needs, some would say a space in group name always produces errors.

Were you also on GitHub? There are some discussions about group sync right now

I'm not familiar with the OpenVPN implementation, but there's no reason that certificate export limitations should prevent authentication and web gui access via LDAP directly, without requiring a local user copy. With respect to LDAP, there is no issues with spaces in a group name, so you could easily accommodate different requirements by using group scopes similar to pfSense.

I'm not suggesting that automatic import of users be removed, just that it not be required for authentication for LDAP.

Can you link me to the discussion on Github? I searched around but didn't find anything.

4

General Discussion / Feedback regarding LDAP Implementation

« on: October 20, 2021, 10:03:26 pm »

I've been using pfSense for a while and decided to check out OPNsense largely because of this issue, but also because I want to support the openness of OPNsense (hah!). So far most of the setup process has been painless, and there is a lot to love! LDAP, however, leaves a bit to be desired.

I'd like to demonstrate why by illustrating how easy and straightforward the setup is in pfSense:

• Add LDAP Authentication Server
• Add a Group with "Scope: Remote" whose name corresponds to an LDAP group (and you can have spaces!) and assign appropriate permissions
• Configure administration acccess to use the LDAP server

That's it! There's no synchronization to the local database or user creation needed, nor should there be; LDAP should be the single source of truth for user information.

OPNSense's implementation is frustrating for a few reasons: group names can't have spaces, which means I have to not only change the group name in my directory, but also any other service that used that group for ACL (in my case, this was pfSense).

Synchronizing groups and importing users is clunky and unintuitive. It's also not consistent (importing via the users page shows the DN, but if you do automatic user creation, it does not). Finally, if a user is removed from LDAP, it is not removed from the synchronized local copy. The documentation notes that this feature is enabled in the business edition, but I'd point out that this is effectively how pfSense works in the community edition (no manual removal needed).

Setting it up was rather painful, and now I find myself considering sticking with pfSense, which has a broken DNS implementation, over using OPNsense.

The synchronization requirement (and group names not able to have spaces) suggests to me that LDAP is sort of an addon that creates local users/groups so it can leverage existing authentication code. I haven't had a chance to dig through the source yet, but I'm curious if there are any fundamental technical limitations that require the implementation to be this way. It would be fantastic if the support for LDAP were first class, meaning it does not have any dependence on local authentication, and does not require user creation or group synchronization.

If the team is interested in improving this, I'd be happy to contribute whether its the code itself, or if that's beyond my skills, sponsoring another developer to do so.