OPNsense Forum
English Forums => Development and Code Review => Topic started by: BertM on August 22, 2016, 11:47:16 am
-
I am using OPNsense version 16.7.2.
With user authentication against a Microsoft AD, some things that already seem to be implemented simply don't work.
In addition, some functionality that makes our life a whole lot easier is not (yet?) there.
Let's start with what is already there.
First of all the basics are working, meaning that I am, for instance, able to let users open an IPsec VPN while validating with their AD user account.
But......any of the 'filtering' options don't work.
The first thing is the 'Search scope'. In the GUI, there is a drop-down box for the Level that allows you to search One level deep or in the entire Subtree of the AD.
No matter what you select here, you always search the entire subtree.
Second thing are the 'Authentication containers'.
This is a required entry, and you should enter an OU (or a semicolon-separated list of OU's) where you would search for user accounts.
No matter what you enter here (you can even enter 'BlaBla'), it will still search the entire AD for User accounts.
I have been playing around with the 'Extended Query', and that seems to work (at least as far as I tested).
For example, to only allow users that are member of a certain group, one could enter something like:
memberOf=CN=Some_Group,OU=Security Groups,OU=Some_OU,DC=DOMAIN,DC=TopDomain
This actually works, but it is not yet what we would like to see.
What would really make me cheer is the ability to validate users based on membership of an AD group (and in OPNsense asign privileges to these AD Groups without specifyling the user account itself) much in the same way as it is implemented in pfSense.
One other thing in the GUI is that going to System ==> Access ==> Settings and clicking Save and Test button will trigger the pop-up blocker.
Just drop me an e-mail if you need more info, want me to demonstrate the issues via TeamViewer, or want me to test something.
Kind regards,
Bert
-
Hello,
I just started playing with this AD integration today. I too have come to the same conclusions as the OP. This is really not a complete implementation at all. One of the main benefits of using a directory and putting users in groups is that you can simply rely on the group membership to provide permissions etc... and handle user changes more dynamically.
I haven't tried the pfSense implementation yet but if it works I made need to drop OPNsense.
Is there any plan to fix this any time soon?
Oliver
-
Hi all,
For reference https://github.com/opnsense/core/issues/1169 (https://github.com/opnsense/core/issues/1169) ldap support for the gui in our case always requires a linking pin in our config. We might add some kind synchronisation at some point, but the architecture won't change (clear separation of concerns).
There are no concrete plans the create a sync script at the moment.
When using services such as openvpn it's rather easy to use the ldap group membership, see our documentation for details.
Best regards,
Ad
-
Thanks for the update and direction.
I think we're less concerned how it's done vs that it's done. I can live with having to create a new account based on an LDAP entry but there are still some ways to make that process more streamlined for us. E.g., if I authenticate against the firewall and my name is in an LDAP group, then auto create the account for me and assign it the Privileges needed based off what the LDAP group has been assigned in the firewall (I'm assuming that means I'd need to manually create a local group based off the LDAP entry as well, which is fine as long as I only have to do it once).
That said, it's really in the best interest of the product to be as seamless as possible when it comes to LDAP integration. The more you can pull in the the directory, the better. If you don't need to sync at all because you're querying real-time all the time, that's an even bigger plus.
-
Hi Oliver,
The biggest question is: who will put in the work to get it done on time. :)
I don't think we can cover all desired aspects with the resources we have vs. the resources we ought to have to not delay any requests and ideas coming from the community.
So far, things have been handled hands-down, managing (too many) concurrent requests, prioritising items in a long queue, making gradual improvements to the project ever since 15.1 came out.
It's already been two years of this kind of effort and it's very much planned to keep it going. I hope that users agree that improvements have been steady and that each new major release also addresses major pains of the previous one.
If improvements are needed sooner, there are methods to achieve that. That's what Deciso excels at. If not, we need to keep the OPNsense roadmap aligned and balanced for the community at large.
AD is one of those areas that cross into corporate territory, not many home users or non-windows companies will be interested. There was larger feedback and also contributions from the community in 2015 to get the current integration to where it's at. I'm not aware of much requests in 2016 that couldn't be solved otherwise or were not deemed "mission critical".
I felt like mentioning this because it keeps popping up in different areas of the project and managing / leveling expectations is something that is important too.
Cheers,
Franco
-
Thanks for the honest reply, Franco.
I do understand your position. I also still have my agenda which I am not embarrassed to push :)
You can also look at it from this perspective: Corporate users are the ones with the money. If you make your product more attractive to them (so that it addresses common management and compliance requirements), they're more able to give back from a financial perspective.
Either way, I'm looking at OPNsense for a reason, so you are obviously doing something better than other competing products. Also, you are much friendlier to deal with than the pfSense guys who banned me for life from their forum and won't tell me why even though I only ever posted 1 message asking about quagga integration!
Keep up the good work! oh, and add some enterprise features I want too :)
-
Well, I need you and everyone else to keep doing what you are doing. It's obviously very good for the project. :)
The entry level for a corporate user is high. If we have a bigger fish we cannot meet requirements until a few of the little ones have raised the bar. So it all takes time to get there.
Downloads are picking up, stability has increased quite a bit. Once we have the reported kernel issues out of the way we will continue to work on authentication improvements and let's see how far this will get the AD support. We'll make some noise when we are there.
If you can help test features that are of interest to you that would be even better. The opnsense-devel package is easy to install on a test system. Well, this and keeping up the feedback.
Thanks,
Franco
-
Sounds good, Franco!
I'm very willing to test the LDAP integration features. I wouldn't consider myself a developer so working on code is probably not what I'll be good for, but I can certainly test, advise, and provide technical and business-level feedback.
On a similar note, I was playing with the access privileges a bit and it would be great if you could provide some mechanism for giving admin access to pages with more granularity. Page-level is still fine. A use case would be a VPN administrator: They would need to be able to admin the VPN-related pages but I wouldn't want them messing around in the Services pages.
Just let me know if there are some new enterprise features you need tested.
Oliver
-
I guess I just have to be patient and wait untill the dust settles over the other issues, and there is time for improving LDAP integration.
We are slowly migrating from Cisco, Juniper, and pfSense towards OPNsense, and this does not happen over night.
We are going site by site, and I will just change the order in which we do things so that we migrate the ones where LDAP integration is important as the last ones.
Hopefully, by that time, LDAP integration will be better.
Just keep in mind that, just like ooboyle, we are migrating to OPNsense because we already think it is the better alternative in our environment.
So keep up the good work.
I am not a programmer, but I am in a position where I can test LDAP integration in environments of different size.
Just let me know if I can help there.
Regards,
Bert
-
I noticed that, with version 16.7.11, a big step forward is already made, but we are not there yet.
The 'filtering' options (Search scope and Authentication containers) now work as they should.
Because also the Extended query works as expected, almost all ingredients we need seem to be in place.
It is just that last little hurdle of putting it all together that still needs to be taken before we can validate users based on group membership in the Microsoft Active Directory.
The whole purpose (at least for me) is to allow users to use their Microsoft AD account for validation to establish a Mobile IPSec connection.
In the server configuration in System ==> Access ==> Servers, I added the proper Authentication containers and search scope.
Attemping to import users using the little cloud button in System ==> Access ==> Users, this already reduced the size of the list significantly, but I am still looking at a list of almost a hundred users.
This is where the Extended query comes to help.
In the Extended query field I entered:
|(memberOf=CN=Group1,OU=Security Groups,DC=DOMAIN,DC=TLD)(memberOf=CN=Group2,OU=Security Groups,DC=DOMAIN,DC=TLD)
The first character (the pipe-sign) means 'or', so if the user is member of Group1 OR is member of Group2, he will pass this filter.
When I attempt to import users again, the list is now limited to only the users that are member of one of the groups.
That is already a great help.
But I did not import any users yet, because there was one more thing I would like to test.
I navigated to System ==> Access ==> Tester and tested various with AD user accounts.
Only those accounts that are member of one of the groups that were defined in the Extended query were able to test successfully, even though they were not imported.
This is already so close to where we want to go!
There are just a few things missing. Wouldn't it be nice if the following scenario would work:
Under System ==> Access ==> Groups, it would be nice to be able to import groups from the Microsoft AD in the same way as how we can import users.
In the configuration of the group, we can than assign the 'VPN: IPsec XAUTH dialin' privilege.
A user then attempts to establish a VPN connection and enters his Microsodt AD credentials.
OPNSense forwards the credentials to the AD server, the server returns the groups the user is member of.
If one of these groups matches the group we previously imported, the related privileges (VPN: IPsec XAUTH dialin) are allowed.
This means that by just importing the AD group, users can establish a IPSec VPN based on group membership.
Wouldn't that be nice.
Kind regards,
Bert
-
Hi Bert,
I agree that would be nice. If we could pull group info from the LDAP on user authentication and provide the same type of import that we allow for users this would work.
The biggest pitfall is the assumption that local users/groups are synced again, though they are just snapshot clones of the LDAP entries and do not even hold the correct passwords.
FWIW, integrated PAM authentication is finally rolled out in 17.1, which could even solve the issue of cloned users being able to authenticate against their native LDAP starting with SSH and the console, GUI and all the way up to OpenVPN/IPsec.
Cheers,
Franco