Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - ooboyle

#1
Franco,

Thanks for looking into this in more detail. Based on what you said in reply #5, it sounds like the preferred approach is for them to rebuild their mirror on the latest FreeBSD ports. Does that still hold true?

If so, I'll see if I can alert them to the situation and request a rebuild.

Oliver
#2
Franco,

I'd be happy to use the saltstack repo as per: https://docs.saltstack.com/en/latest/topics/installation/freebsd.html

But when I tried to install it, it wouldn't work. Some very minor dependency issue, is seemed. If you can get that working, it would also be an acceptable path forward.

I do understand about wanting to keep your repo slim but config mgmt tools are becoming more and more common. If you want enterprises to jump in, this is a must. You'd hit the majority with salt, chef, and puppet.

Oliver
#3
Thanks, Franco.

Yes, I assumed that would be the answer. I took a snapshot, added the package, updated opnsense as well, and all works fine.

Given that salt is a config mgmt tool, and therefore quite likely that many people would benefit from having it's presence supported by opnsense, are you able to add it to your repo?

I'm not a fan of compiling directly. Packages only.

Oliver
#4
Running:

OPNsense 17.1.6-amd64
FreeBSD 11.0-RELEASE-p8
OpenSSL 1.0.2k 26 Jan 2017

Can I safely enable the FreeBSD repo?

I need to install py27-salt and any dependencies.

Oliver
#5
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
#6
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 :)

#7
Ok, here's the timeline. In this case, it took about 3 minutes, and 3 attempts during that period, for the LDAP account to show its membership in the group I added it too.


Added the LDAP user:

--- /conf/backup/config-1474914232.0974.xml   2016-09-26 14:23:52.098111000 -0400
+++ /conf/config.xml   2016-09-26 14:23:55.225032000 -0400
@@ -845,7 +845,7 @@
   </widgets>
   <revision>
     <username>admin@192.168.1.164</username>
-    <time>1474914231.4041</time>
+    <time>1474914235.217</time>
     <description>/system_usermanager_import_ldap.php made changes</description>
   </revision>
   <cert>

1st attempt at adding it to a group:

--- /conf/backup/config-1474914281.1166.xml   2016-09-26 14:24:41.117074000 -0400
+++ /conf/config.xml   2016-09-26 14:24:44.028389000 -0400
@@ -845,7 +845,7 @@
   </widgets>
   <revision>
     <username>admin@192.168.1.164</username>
-    <time>1474914280.5169</time>
+    <time>1474914284.0206</time>
     <description>/system_usermanager_import_ldap.php made changes</description>
   </revision>
   <cert>

2nd attempt at adding it to a group:

--- /conf/backup/config-1474914352.377.xml   2016-09-26 14:25:52.377883000 -0400
+++ /conf/config.xml   2016-09-26 14:25:55.215759000 -0400
@@ -845,7 +845,7 @@
   </widgets>
   <revision>
     <username>admin@192.168.1.164</username>
-    <time>1474914351.7208</time>
+    <time>1474914355.2077</time>
     <description>/system_usermanager_import_ldap.php made changes</description>
   </revision>
   <cert>

3rd attempt at adding it to a group:

--- /conf/backup/config-1474914423.9222.xml   2016-09-26 14:27:03.922753000 -0400
+++ /conf/config.xml   2016-09-26 14:27:03.930653000 -0400
@@ -195,6 +195,7 @@
       <gid>1999</gid>
       <member>0</member>
       <member>2000</member>
+      <member>2007</member>
       <priv>page-all</priv>
       <priv>user-shell-access</priv>
     </group>
@@ -225,6 +226,10 @@
       <descr>Oliver O'Boyle</descr>
       <password>$6$$uvbAZquGaG4XqHeTo2ZZO5SJRYs1RutnSksO458ZD5mGaKZyaKYLOVPJNGe7LKrjagR9EdwExN./YlOQxNse71</password>
       <uid>2007</uid>
+      <expires/>
+      <authorizedkeys/>
+      <ipsecpsk/>
+      <otp_seed/>
     </user>
     <nextuid>2008</nextuid>
     <nextgid>2001</nextgid>
@@ -845,8 +850,8 @@
   </widgets>
   <revision>
     <username>admin@192.168.1.164</username>
-    <time>1474914384.6145</time>
-    <description>/system_usermanager_import_ldap.php made changes</description>
+    <time>1474914423.9228</time>
+    <description>/system_usermanager.php made changes</description>
   </revision>
   <cert>
     <refid>56fe90d2e373c</refid>
#8
I've noticed a delay in being able to edit a new user added from LDAP. The user account gets created locally as expected but when I go into the account to assign it a group membership or directly assign it privileges, my changes are not saved and revert to being empty. It take over 5 minutes for this to clear and I'm still unsure if it clears on it's own or because I clicked 100 different buttons while I was waiting.

Is this a known issue?

Oliver
#9
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.
#10
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
#11
Thanks, Franco.

Oliver
#12
Thanks for digging into this Franco. Any chance we can get this added to a bug list and patched?
#13
Thanks, Bill. If it's not too much to ask, re-try SNMP-only after completely uninstalling all monitoring agents.

Thanks,
Oliver
#14
Tested on cmk 1.2.8p4 and same result.

Bill, I'd love to know if you installed the cmk agent or if you're just using SNMP.
#15
Hmm...

I'm running 1.2.6p9 but have a 1.2.8p4 that I can test with as well.

Did you install the cmk agent on the OPNsense devices or are you using just SNMP?

Oliver