LDAP dynamic user creation

[ciroiriarte]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

For an actual centralized user management model, I'm missing a solution for user management and privilege delegation from an LDAP directory. As of today, user provisioning demands firewall configuration after adding each new user.

With the current configuration, after creating a user, I have to go to the firewall to import him/her. Still unsure about deleting them.

Describe the solution you like

I would like to have automatic delegation of permissions, assigning users to groups in the LDAP directory, and mapping the firewall groups to that LDAP group, without having to touch the firewalls while provisioning each user.

Usually, all the platforms that integrate with LDAP directories, implement filters to associate groups (memberOf attributes) to platform roles automatically. Once a user is added to the correct group, he/she automatically gets access granted, taking into account the RBAC definitions (fwadmin group has full control, noc group will get a subset of the privileges). When the user gets disabled, deleted or removed from the group in the directory, they automatically lose access to the firewall.

Describe alternatives you considered

Currently using it as is, but importing user by user is not practical for the regular lifecycle (adding/deleting users, changing access levels/groups, etc).

Additional context

Have OPNsense 21.1.8_1-amd64 integrated with FreeIPA, with the current use model.

[ciroiriarte]

Also with the current "implicit" group integration, members of "admins" group from LDAP are automatically granted access as admins, even though they are not supposed to have access (directory admins vs firewall admins).

Group to filter mapping would be more appropriated.

[AdSchellevis]

The user creation process is still somewhere on the wishlist, a long time ago we started with the import, during the years we added group sync which makes it more logical to move the creation to the login process. (optionally removing the current import in the future as well).

core/src/opnsense/mvc/app/library/OPNsense/Auth/LDAP.php

Lines 505 to 510 in 78c8be7

	// update when changed
	if ($user == null) {
	// user creation not supported (yet)
	// XXX: we might consider this in the future, since legacy code is involved in creating users
	return;
	}

Cleaning up users will always be a bit problematic, you could add some job removing the ones that haven't been used for a long time, but from OPNsense's perspective it can't know if the user still exists.

Mappings I'm personally not sure about, since you can already limit the scope of the sync (explicit include groups to sync) a mapping will basically be something quite comparable to a group already in my honest opinion.

These tickets are basically the same by the way #4660, #4963. If we can settle for the user creation process, I'm willing to put a feature label on the ticket and assign my name to it (no promises on when it will there, it's more or less a spare time project)

[ciroiriarte]

if the user is not listed in the directory anymore, you purge it (given you had a proper return from the directory). What about all that being configurable?.

For example, here it's explained how Proxmox does it: https://forum.proxmox.com/threads/new-ldap-sync-feature-questions-around-full-sync-and-eta.69260/

The only missing part is the automation. Some projects do it on a scheduled basis (can be used as a workaround with Proxmox, to run the sync command via cron), other projects do the sync/creation/cleanup pre-login, every time a user tries to login. The scheduled option may miss the real directory state as a source of truth when needed (user won't have access until next execution, worse in a very dynamic environment), but will be eventually consistent.

The sync-pre-login, grants inmediate consistency at the expense of running the full process before each login.

Since posting, found that I could chose the groups in "limit groups", which works in my case (excluding pirate admins, not so dynamic lab, will grant access only on 3 roles), for people actually using this heavily it may not be enough.

Only issue would be for people with the same name on both sides but with different purposes. Also, once creating a new group in the directory, we have to head back to the firewall to explicitly allow it.

Another option would be to have filters for inclusion, instead of explicit inclusion, for example: importing only '&(objectclass=groupofnames)(cn=gfwusr-*)', will import 'gfwuser-admin', 'gfwuser-noc' and 'gfwuser-audit' and whatever else is created afterwards with the same pattern.

Now, priviledge access can be done once per imported group (one time, I'm fine with this), more hardcore usage of LDAP could get those priviledges from the directory also (group extended attributes), assuming there's a class that we could lean on.

About the users, one option is to include all the users that match a pattern (filter again), or just import the users that are actually members of the groups that show up according to the other filter ('member' attributes have the full DN of each user)

And regarding clean-up, it could be configurable, you don't have to hardcode it. Some users would prefer the directory as a single source of truth, other won't.

At the end of the day, the requirement would be: not having to touch the firewall when adding users to existing groups. That means, setting up the ACL once by hand (after importing the group?), and autocreating/autodeleting users based on DN stated in "member' attribute of the groups that come from the group import filter.

Thanks for the feedback!

[AdSchellevis]

To be very honest, if we would add a synchronisation function (which I'm not sure yet is a good idea), it would likely more be a feature for the business edition of our product. User creating on login is a flow which from a code perspective is a feature that belongs more to the existing base, a sync is a more separated feature for enterprise users.

[ciroiriarte]

Well, "user creation on login" with the automatic association to the groups (which works today already) would work for me 😊. What I don't think scales is going to the firewall to manually import a user after adding it the group on the directory side.

Would the difference for you be more related to the batch/bulk nature of the "synchronization" option?.

[AdSchellevis]

Would the difference for you be more related to the batch/bulk nature of the "synchronization" option?.

More where it lives, if it's part of the login sequence its more logical to add in the existing spot. If we can separate it (and put a lot of work in it), I'm not sure why enterprise users wouldn't pay a bit for our efforts as well.... There are always alternative options, such as building custom scripts to do the work.

[ciroiriarte]

Understood. To exted the request :), can that "creation on login" include populating additional attributes?. As of today, the manual import doesn't include SSH keys (ipaSshPubKey and/or sshpubkeyfp attributes), or shell (loginshell attribute)

[AdSchellevis]

currently not planning to, I don't think their very standard across implementations either.

[AdSchellevis]

With 4414ffd it's possible to automatically create users after successful login when the remote host returns group memberships.

Just check the following option in an existing LDAP config, you can use the tester to create/sync the user as well as using the normal login workflow.

[mimugmail]

And finally a toggle to autocreate a client certificate when logged in? 😍

[AdSchellevis]

@mimugmail there was kind of a promise in the source, waiting to be fulfilled.