mavis_tacplus-ng_ldap.pl backend

[Petr Issakov]

Hi, Marc!

I'm testing mavis_tacplus-ng_ldap.pl backend

When I configure several ldap hosts:

setenv LDAP_HOSTS = "ldaps://1.1.1.1:636 ldaps://2.2.2.2:636"

Backend not working.

 In logs I see messages:

Apr 10 13:17:13 t2ru-tacacs-vm-01 tac_plus-ng[2267978]: /usr/local/lib/mavis/mavis_tacplus-ng_ldap.pl: 2268017: Expected 'PeerHost' at /usr/share/perl5/vendor_perl/Net/LDAP.pm line 173

[Marc Huber]

Hi Petr,

I'm sorry, I don't believe I can really help with that issue.
"vendor_perl" indicates Alpine, and I really don't have a test setup for
that.

On Ubuntu 22.04 I don't see this error, so the Perl setup may differ.
"PeerHost" is likely related to IO::Socket::SSL which may or may not be
the root cause.

If mavis_tacplus-ng_ldap.pl doesn't work for you, then there's still a
chance that mavis_tacplus_ldap.py or ldapmavis-mt will. Those should
come with the same features, but other run-time dependencies.

Cheers,

Marc

> --
> You received this message because you are subscribed to the Google
> Groups "Event-Driven Servers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to event-driven-ser...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/event-driven-servers/69f5d527-441f-43e6-a179-51d1ace7db6bn%40googlegroups.com
> <https://groups.google.com/d/msgid/event-driven-servers/69f5d527-441f-43e6-a179-51d1ace7db6bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Petr Issakov]

Hi Marc!
It's strange. issue still exist when I use connection without ssl. when I try old backend (mavis_tacplus_ldap.pl) it work fine with same config.

And one more thing, I've noticed that new backend  mavis_tacplus-ng_ldap.pl  work with Ldap much more slowly than mavis_tacplu_ldap.pl
I take dump and saw that for some reasons backend take searchRequest for all groups in memberof user attribute (see screenshot in attach)
This generates huge amount of requests and take long time
In compare old backend not generate searchRequest for each group and work faster

четверг, 11 апреля 2024 г. в 00:31:54 UTC+6, Marc Huber:

[Marc Huber]

Hi Petr,

I've just modified the mavis_tacplus-ng_ldap.pl code to handle
LDAP_HOSTS similar to mavis_tacplus_ldap.pl. While I see no difference
in behaviour, it might give you a better result.

You can use the LDAP_MEMBEROF_REGEX variable to limit recursive group
searches to the ones you're actually using. Default is "^cn=([^,]+),.*",
and for adding a "tacacs_" prefix ("^cn=(tacacs_[^,]+),.*") would skip
non-matching memberOf entries.

Cheers,

Marc

[Petr Issakov]

Hi, Marc!

I've just modified the mavis_tacplus-ng_ldap.pl code to handle
LDAP_HOSTS similar to mavis_tacplus_ldap.pl. While I see no difference
in behaviour, it might give you a better result.

Thank you! For me now LDAP_HOSTS working fine! 

You can use the LDAP_MEMBEROF_REGEX variable to limit recursive group
searches to the ones you're actually using. Default is "^cn=([^,]+),.*",
and for adding a "tacacs_" prefix ("^cn=(tacacs_[^,]+),.*") would skip
non-matching memberOf entries.

LDAP_MEMBEROF_REGEX working after recursive group search and filtering out last result

I've noticed that in old backend mavis_tacplus_ldap.pl has env var EXPAND_AD_GROUP_MEMBERSHIP which undef by default.

As result old backend not expanding all groups recursively and work faster

In my case users contains more than 100 groups in memberof attr and expanding all groups take more than 7 seconds

I added condition from your old backend to new mavis_tacplus-ng_ldap.pl:

my $expand_ad_group_membership = undef;

$expand_ad_group_membership = $ENV{'EXPAND_AD_GROUP_MEMBERSHIP'} if exists $ENV{'EXPAND_AD_GROUP_MEMBERSHIP'};

......

 $mesg = $ldap->search(base => $LDAP_BASE, filter => sprintf($LDAP_FILTER, $V[AV_A_USER]), scope => $LDAP_SCOPE,
                attrs => ['shadowExpire','memberOf','dn', 'uidNumber', 'gidNumber', 'loginShell', 'homeDirectory', 'sshPublicKey',
                          'krbPasswordExpiration', $LDAP_TACMEMBER]);
        if ($mesg->count() == 1) {
                my $entry = $mesg->entry(0);

                my $val = $entry->get_value('memberOf', asref => 1);
                $authdn = $entry->dn;
                my (@M, @MO);
                if ($#{$val} > -1) {
                        $val = expand_memberof($val) if defined $expand_ad_group_membership;
                } else {
                        $val = expand_groupOfNames($entry->dn) if defined $expand_ad_group_membership;
                }
                foreach my $m (sort @$val) {
                        if ($m =~ /$LDAP_MEMBEROF_REGEX/i) {
                                push @M, $1;
                                push @MO, $m;
                        }
                }

........

Now new backend works a lot faster for me

It would be great if you provide this option for new backend in git

Thank you!

пятница, 12 апреля 2024 г. в 19:42:56 UTC+6, Marc Huber:

[Marc Huber]

Hi Petr,

thanks again for testing and evaluating the recent code!

I need a bit more time to think about the memberOf recursions, as those
should be covered by the Perl, Python, any C backends, similary. I'll
possibly add some kind of "recursion depth" parameter to cope with this
issue. Not sure about that one right now.

Thanks,

Marc

[Marc Huber]

Hi Petr,

the latest commit adds support for a LDAP_NESTED_GROUP_DEPTH environment
variable.

setenv LDAP_NESTED_GROUP_DEPTH = <n> # limit to <n> levels

This should work with ldapmavis-mt, mavis_tacplus-ng_ldap.pl and
mavis_tacplus_ldap.py.

Cheers,

Marc

[Petr Issakov]

Hi Marc! 

Thank you!

I've tested latest   mavis_tacplus-ng_ldap.pl with  LDAP_NESTED_GROUP_DEPTH 

I expect that LDAP_NESTED_GROUP_DEPTH  = 0 config should disable expanding nested groups but I  noticed that if I configure  setenv   LDAP_NESTED_GROUP_DEPTH  = 0 - recursively groups expanding work anymore

Then I try set  LDAP_NESTED_GROUP_DEPTH  = -1 and in this case backend stopping expanding groups but filtering group by LDAP_MEMBEROF_REGEX not work.

воскресенье, 21 апреля 2024 г. в 13:27:20 UTC+6, Marc Huber:

[Vitaly N.]

Hi Marc!

Apologies for bumping an old thread, I can make a new one if that's better. I am trying to troubleshoot the exact same issue with latency because of numerous queries.

I can see all the queries in the LDAP server logging, and setting LDAP_NESTED_GROUP_DEPTH = -1 fixes the latency issue, but then authentication by group no longer works (probably because of the regex issue Petr pointed out)

I've attached our current very simplistic configuration.

Here is I think the relevant bit:

id = tac_plus-ng {
    mavis module = external {
        setenv LDAP_SERVER_TYPE = "generic"
        setenv LDAP_HOSTS = "ldaps://duo1:12346"
        setenv LDAP_BASE = "cn=users,cn=accounts,dc=company,dc=net"
        setenv LDAP_BASE_GROUP = "cn=groups,cn=accounts,dc=company,dc=net"
        setenv LDAP_USER = "uid=tacacsuser,cn=users,cn=accounts,dc=company,dc=net"
        setenv LDAP_PASSWD = "bind_password"
        setenv LDAP_MEMBEROF_REGEX = "^cn=(tacacs[^,]+),.*"
        setenv LDAP_NESTED_GROUP_DEPTH = 0
        exec = /tacacs/lib/mavis/mavis_tacplus-ng_ldap.pl
    }

Thanks for any insight!

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. 

[Marc Huber]

Hi,

the recursion depth check looks misplaced. Care to try the modifications
below?

Cheers,

Marc


--- a/mavis/perl/mavis_tacplus-ng_ldap.pl
+++ b/mavis/perl/mavis_tacplus-ng_ldap.pl
@@ -206,7 +206,6 @@ sub expand_groupOfNames($) {
 sub expand_memberof($) {
        sub expand_memberof_sub($$$) {
                my $depth = $_[2];
-               return if defined($LDAP_NESTED_GROUP_DEPTH) &&
$LDAP_NESTED_GROUP_DEPTH <= $depth;
                sub get_memberof($) {
                        my $mesg = $ldap->search(base => $_[0],
scope=>'base', filter=>'(objectclass=*)', attrs=>['memberOf']);
                        if ($mesg->code){
@@ -223,11 +222,13 @@ sub expand_memberof($) {
                foreach my $m (@$a) {
                        unless (exists $H->{$m}) {
                                $H->{$m} = 1;
+                               if (defined($LDAP_NESTED_GROUP_DEPTH) &&
$LDAP_NESTED_GROUP_DEPTH <= $depth) {
                                        my $g = get_memberof($m);
expand_memberof_sub($g, $H, $depth + 1);
+}
                        }
                }
        }

        my %H;
        expand_memberof_sub($_[0], \%H, 0);

On 05.02.2025 17:15, Vitaly N. wrote:
>
> Hi Marc!
> Apologies for bumping an old thread, I can make a new one if that's
> better. I am trying to troubleshoot the exact same issue with latency
> because of numerous queries.
> I can see all the queries in the LDAP server logging, and setting

> LDAP_NESTED_GROUP_DEPTH = -1fixes the latency issue, but then

> authentication by group no longer works (probably because of the regex
> issue Petr pointed out)
> I've attached our current very simplistic configuration.
>
> Here is I think the relevant bit:
>
> id = tac_plus-ng {
>     mavis module = external {
>         setenv LDAP_SERVER_TYPE = "generic"
>         setenv LDAP_HOSTS = "ldaps://duo1:12346"
>         setenv LDAP_BASE = "cn=users,cn=accounts,dc=company,dc=net"
>         setenv LDAP_BASE_GROUP = "cn=groups,cn=accounts,dc=company,dc=net"
>         setenv LDAP_USER =
> "uid=tacacsuser,cn=users,cn=accounts,dc=company,dc=net"
>         setenv LDAP_PASSWD = "bind_password"
>         setenv LDAP_MEMBEROF_REGEX = "^cn=(tacacs[^,]+),.*"
>         setenv LDAP_NESTED_GROUP_DEPTH = 0
>         exec = /tacacs/lib/mavis/mavis_tacplus-ng_ldap.pl
>     }
>
> Thanks for any insight!
> On Monday, May 13, 2024 at 5:35:58 AM UTC-4 Petr Issakov wrote:
>
> Hi Marc!
> Thank you!
> I've tested latest mavis_tacplus-ng_ldap.pl

> <http://mavis_tacplus-ng_ldap.pl/> with LDAP_NESTED_GROUP_DEPTH

> I expect that LDAP_NESTED_GROUP_DEPTH  = 0 config should disable
> expanding nested groups but I  noticed that if I configure 
> setenv   LDAP_NESTED_GROUP_DEPTH  = 0 - recursively groups
> expanding work anymore
> Then I try set LDAP_NESTED_GROUP_DEPTH  = -1 and in this case
> backend stopping expanding groups but filtering group by
> LDAP_MEMBEROF_REGEX not work.
>
> воскресенье, 21 апреля 2024 г. в 13:27:20 UTC+6, Marc Huber:
>
> Hi Petr,
>
> the latest commit adds support for a LDAP_NESTED_GROUP_DEPTH
> environment
> variable.
>
> setenv LDAP_NESTED_GROUP_DEPTH = <n> # limit to <n> levels
>
> This should work with ldapmavis-mt, mavis_tacplus-ng_ldap.pl

> <http://mavis_tacplus-ng_ldap.pl> and

> mavis_tacplus_ldap.py.
>
> Cheers,
>
> Marc
>
>
> On 17.04.2024 18:28, Marc Huber wrote:
> > Hi Petr,
> >
> > thanks again for testing and evaluating the recent code!
> >
> > I need a bit more time to think about the memberOf
> recursions, as
> > those should be covered by the Perl, Python, any C backends,
> similary.
> > I'll possibly add some kind of "recursion depth" parameter
> to cope
> > with this issue. Not sure about that one right now.
> >
> > Thanks,
> >
> > Marc
> >
> >
>
>
> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and is
> protected by law. If you are not the intended recipient, you should
> delete this message and are hereby notified that any disclosure,
> copying, or distribution of this message, or the taking of any action

> based on it, is strictly prohibited. --

> You received this message because you are subscribed to the Google
> Groups "Event-Driven Servers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to event-driven-ser...@googlegroups.com.

> To view this discussion visit
> https://groups.google.com/d/msgid/event-driven-servers/82c59bcd-8509-4781-aeb4-bb9c37b255c0n%40googlegroups.com
> <https://groups.google.com/d/msgid/event-driven-servers/82c59bcd-8509-4781-aeb4-bb9c37b255c0n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Vitaly N.]

Hi Marc, thanks for this! Unfortunately no change from a latency nor number of requests perspective. But you got me to dig in and I realized that the regex was being ignored until all the queries finished. 

This change fixed the issue for me. What do you think? Admittedly this isn't my wheelhouse so I can't foresee if this breaks configurations other than mine.

--- a/mavis/perl/mavis_tacplus-ng_ldap.pl
+++ b/mavis/perl/mavis_tacplus-ng_ldap.pl
@@ -356,17 +356,17 @@ retry_once:

                my $val = $entry->get_value('memberOf', asref => 1);
                $authdn = $entry->dn;
                my (@M, @MO);

-               if ($#{$val} > -1) {
-                       $val = expand_memberof($val);
-               } else {
-                       $val = expand_groupOfNames($entry->dn);
-               }

                foreach my $m (sort @$val) {
                        if ($m =~ /$LDAP_MEMBEROF_REGEX/i) {
                                push @M, $1;
                                push @MO, $m;
                        }
                }

+               if ($#{$val} > -1) {
+                       $val = expand_memberof(\@MO);
+               } else {
+                       $val = expand_groupOfNames($entry->dn);
+               }
                $V[AV_A_TACMEMBER] = '"' . join('","', @M) . '"' if $#M > -1;
                $V[AV_A_MEMBEROF] = '"' . join('","', @MO) . '"' if $#MO > -1;
                $V[AV_A_DN] = $authdn;

[Marc Huber]

Hi,

basically, you diff moves regex checking before recursive evaluation,
but I'm really not sure whether that's the right thing to do. E.g., for
- user is member of group A
- group A comes with memberOf=tac_A
- regex filter is /^tac_/
recursive membership would not be detected.

I'll have a closer look at this issue and set up a test environment
if/when I find the time.

Cheers,

Marc

> <http://mavis_tacplus-ng_ldap.pl>
> +++ b/mavis/perl/mavis_tacplus-ng_ldap.pl
> <http://mavis_tacplus-ng_ldap.pl>

> <http://mavis_tacplus-ng_ldap.pl>

> <https://groups.google.com/d/msgid/event-driven-servers/82c59bcd-8509-4781-aeb4-bb9c37b255c0n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
>
>
> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and is
> protected by law. If you are not the intended recipient, you should
> delete this message and are hereby notified that any disclosure,
> copying, or distribution of this message, or the taking of any action
> based on it, is strictly prohibited. --
> You received this message because you are subscribed to the Google
> Groups "Event-Driven Servers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to event-driven-ser...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/event-driven-servers/77868707-e6a0-4a94-8e44-07105f1afb0dn%40googlegroups.com
> <https://groups.google.com/d/msgid/event-driven-servers/77868707-e6a0-4a94-8e44-07105f1afb0dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Nilesh Lahim]

Hi Marc!,

We have installed tacacs Server Version 0.9.83,We are facing lots of issue,

- We are unable to login from created tacacs user to device (telnet 172.23.60.8 user ) error is getting incorrect username and password.

- Authentication,authorization and accounting log are not found in the report.

- in MAVIS Setting tacacs Users are not showing.

- LDAP configuration is required for tacacs Server Version 0.9.83

- Pls help to us and  share complete process to configure tacacsGUI Server

user = nilesh {
    login = mavis # Local Database
    member = defaultUserGroup
    pap = login # Clone login
    enable = login # Clone login
    server = permit huawei # 172.23.60.8
    server = permit 94408 # 172.23.60.7/24
    server = deny 0.0.0.0/0 # permit ONLY
    ###Service huawei START###
    service = shell {
      set priv-lvl = 15
    } #END OF Huawei General Service
    service = shell {
      set priv-lvl = 15
    } #END OF Extreme Networks Service
    ###Service huawei END###
    ###Service 94408 START###
    service = shell {
      set priv-lvl = 15
    } #END OF Huawei General Service
    service = shell {
      set priv-lvl = 15
    } #END OF Extreme Networks Service
    ###Service 94408 END###
  } #END OF nilesh

Thanks,

Nilesh 

--

You received this message because you are subscribed to the Google Groups "Event-Driven Servers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to event-driven-ser...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/event-driven-servers/82c59bcd-8509-4781-aeb4-bb9c37b255c0n%40googlegroups.com.

--

Thanking You,
 Nilesh Lahim 
 E-Mail:-nl...@gmail.com
 

[Vitaly N.]

That's a fair point. Perhaps the answer then is to only skip the recursive membership lookup if LDAP_NESTED_GROUP_DEPTH=0 (otherwise the meaning of setting this to 0 is not clear to me). 

Look forward to seeing what you come up with. Thanks again Marc!

[Marc Huber]

Hi,

first, please don't hijack threads. This has no relevance to tac_plus-ng
or the NG-specific Perl backend.

Second, the tac_plus version you're using is close to 5 years old and
clearly unsupported. Also, TACACSGUI is authored and maintained by
Aleksey Mochalin, so it might make sense to ask Aleksey at tacacsgui.com
or whatever communication channels he provides.

Thanks,

Marc

On 07.02.2025 08:01, Nilesh Lahim wrote:
> Hi Marc!,
>
> We have installed tacacs Server Version 0.9.83,We are facing lots of
> issue,
>
> - We are unable to login from created tacacs user to device (telnet
> 172.23.60.8 user ) error is getting incorrect username and password.
> - Authentication,authorization and accounting log are not found in the
> report.
> - in MAVIS Setting tacacs Users are not showing.
> - LDAP configuration is required for tacacs Server Version 0.9.83
> - Pls help to us and share complete process to configure tacacsGUI Server
>
>

> <snip>
>
> <snip>
>
> user =nilesh {
> login =mavis # Local Database
> member =defaultUserGroup
> pap =login # Clone login
> enable =login # Clone login
> server =permit huawei# 172.23.60.8
> server =permit 94408# 172.23.60.7/24 <http://172.23.60.7/24>
> server =deny 0.0.0.0/0 <http://0.0.0.0/0># permit ONLY

> ###Service huawei START###
> service =shell {
> set priv-lvl =15
> }#END OF Huawei General Service
> service =shell {
> set priv-lvl =15
> }#END OF Extreme Networks Service
> ###Service huawei END###
> ###Service 94408 START###
> service =shell {
> set priv-lvl =15
> }#END OF Huawei General Service
> service =shell {
> set priv-lvl =15

> }#END OF Extreme Networks Service
> ###Service 94408 END###
> }#END OF nilesh

> <snip>

>
>
> Thanks,
> Nilesh
> On Wed, Feb 5, 2025 at 10:27 PM Vitaly N.
> <vitaly.n...@vaticinvestments.com> wrote:
>
>
> Hi Marc!
> Apologies for bumping an old thread, I can make a new one if
> that's better. I am trying to troubleshoot the exact same issue
> with latency because of numerous queries.
> I can see all the queries in the LDAP server logging, and setting

> LDAP_NESTED_GROUP_DEPTH = -1fixes the latency issue, but then

> authentication by group no longer works (probably because of the
> regex issue Petr pointed out)
> I've attached our current very simplistic configuration.
>
> Here is I think the relevant bit:
>
> id = tac_plus-ng {
>     mavis module = external {
>         setenv LDAP_SERVER_TYPE = "generic"
>         setenv LDAP_HOSTS = "ldaps://duo1:12346"
>         setenv LDAP_BASE = "cn=users,cn=accounts,dc=company,dc=net"
>         setenv LDAP_BASE_GROUP =
> "cn=groups,cn=accounts,dc=company,dc=net"
>         setenv LDAP_USER =
> "uid=tacacsuser,cn=users,cn=accounts,dc=company,dc=net"
>         setenv LDAP_PASSWD = "bind_password"
>         setenv LDAP_MEMBEROF_REGEX = "^cn=(tacacs[^,]+),.*"
>         setenv LDAP_NESTED_GROUP_DEPTH = 0
>         exec = /tacacs/lib/mavis/mavis_tacplus-ng_ldap.pl

> <http://mavis_tacplus-ng_ldap.pl>

>     }
>
> Thanks for any insight!
> On Monday, May 13, 2024 at 5:35:58 AM UTC-4 Petr Issakov wrote:
>
> Hi Marc!
> Thank you!
> I've tested latest mavis_tacplus-ng_ldap.pl

> <http://mavis_tacplus-ng_ldap.pl/> with LDAP_NESTED_GROUP_DEPTH

> I expect that LDAP_NESTED_GROUP_DEPTH  = 0 config should
> disable expanding nested groups but I noticed that if I
> configure  setenv  LDAP_NESTED_GROUP_DEPTH  = 0 - recursively
> groups expanding work anymore
> Then I try set LDAP_NESTED_GROUP_DEPTH  = -1 and in this case
> backend stopping expanding groups but filtering group by
> LDAP_MEMBEROF_REGEX not work.
>
> воскресенье, 21 апреля 2024 г. в 13:27:20 UTC+6, Marc Huber:
>
> Hi Petr,
>
> the latest commit adds support for a
> LDAP_NESTED_GROUP_DEPTH environment
> variable.
>
> setenv LDAP_NESTED_GROUP_DEPTH = <n> # limit to <n> levels
>
> This should work with ldapmavis-mt,

> mavis_tacplus-ng_ldap.pl <http://mavis_tacplus-ng_ldap.pl>

> <https://groups.google.com/d/msgid/event-driven-servers/82c59bcd-8509-4781-aeb4-bb9c37b255c0n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
>
>
> --
>
> Thanking You,
>  Nilesh Lahim
>  E-Mail:-nl...@gmail.com
>

> --
> You received this message because you are subscribed to the Google
> Groups "Event-Driven Servers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to event-driven-ser...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/event-driven-servers/CAA%3Dhot0%2B8xO61OxG-0FiLrZ7%3DXr76oP-WZbdx5DHKbJUKaWgEQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/event-driven-servers/CAA%3Dhot0%2B8xO61OxG-0FiLrZ7%3DXr76oP-WZbdx5DHKbJUKaWgEQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Marc Huber]

Hi,

commit 79fae56c38bbb78966824d7c2c6fbf89192e9e92 fixes
LDAP_NESTED_GROUP_DEPTH handling, please git pull and retry.

Cheers,

Marc

> <https://groups.google.com/d/msgid/event-driven-servers/77868707-e6a0-4a94-8e44-07105f1afb0dn%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
>
>
> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and is
> protected by law. If you are not the intended recipient, you should
> delete this message and are hereby notified that any disclosure,
> copying, or distribution of this message, or the taking of any action
> based on it, is strictly prohibited. --
> You received this message because you are subscribed to the Google
> Groups "Event-Driven Servers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to event-driven-ser...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/event-driven-servers/b6f74fa7-ce96-40c3-a8a3-a5a1bb38fbaen%40googlegroups.com
> <https://groups.google.com/d/msgid/event-driven-servers/b6f74fa7-ce96-40c3-a8a3-a5a1bb38fbaen%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Vitaly N.]

Hi Marc, 

Appreciate your help continuing to look at this!. Unfortunately in my testing I don't see a difference in behavior between commit 79fae56c38bbb78966824d7c2c6fbf89192e9e92 and the prior behavior, tried with both LDAP_NESTED_GROUP_DEPTH=0 and unset. I suspect this is because I don't have nested groups at all.

My feeling is the regex filtering should happen before the call to expand_memberof IF it's known there is no recursion required (i.e. this has been explicitly set). If you're sophisticated enough to explicitly set NESTED_GROUP_DEPTH to zero then I think it's ok to take that code path. 

diff --git a/mavis/perl/mavis_tacplus-ng_ldap.pl b/mavis/perl/mavis_tacplus-ng_ldap.pl
index 264a863..7a4c6c4 100755
--- a/mavis/perl/mavis_tacplus-ng_ldap.pl
+++ b/mavis/perl/mavis_tacplus-ng_ldap.pl
@@ -357,17 +357,27 @@ retry_once:

                my $val = $entry->get_value('memberOf', asref => 1);
                $authdn = $entry->dn;
                my (@M, @MO);
-               if ($#{$val} > -1) {
-                       $val = expand_memberof($val);
-               } else {
-                       $val = expand_groupOfNames($entry->dn);
-               }
-               foreach my $m (sort @$val) {

-                       if ($m =~ /$LDAP_MEMBEROF_REGEX/i) {
-                               push @M, $1;
-                               push @MO, $m;
-                       }
-               }
+                if ($#{$val} > -1 && $LDAP_NESTED_GROUP_DEPTH == 0) {
+                        foreach my $m (sort @$val) {
+                                if ($m =~ /$LDAP_MEMBEROF_REGEX/i) {
+                                        push @M, $1;
+                                        push @MO, $m;
+                                }
+                        }

+                        $val = expand_memberof(\@MO);
+                } else {
+                        if ($#{$val} > -1) {

+                                $val = expand_memberof($val);

+                        } else {
+                                $val = expand_groupOfNames($entry->dn);
+                        }

+                        foreach my $m (sort @$val) {
+                                if ($m =~ /$LDAP_MEMBEROF_REGEX/i) {
+                                        push @M, $1;
+                                        push @MO, $m;
+                                }
+                        }
+                }

The foreach can be abstracted into a subroutine to avoid code duplication, but you get the idea. Do you agree with my thinking?

Thanks!

[Marc Huber]

Hi,

I'll have a closer look at the group filtering code next weekend. It
might make sense to introduce a dedicated configuration variable to
limit group searches, I just need to thinke more about that.

Cheers,

Marc

On 10.02.2025 22:18, Vitaly N. wrote:
> Hi Marc,
>

> Appreciate your help continuing to look at this!. Unfortunately in my
> testing I don't see a difference in behavior between commit
> 79fae56c38bbb78966824d7c2c6fbf89192e9e92 and the prior behavior, tried
> with both LDAP_NESTED_GROUP_DEPTH=0 and unset. I suspect this is
> because I don't have nested groups at all.
>
> My feeling is the regex filtering should happen before the call to

> expand_memberof *IF* it's known there is no recursion required (i.e.

[Marc Huber]

Hi,

commit 70af67e2353949e7ef08e70d05dca6fb4569c562 introduces a
LDAP_MEMBEROF_FILTER variable to the various LDAP backends (Perl,
Python, C) which can be set to limit LDAP memberOf lookups. Does this
work for you?

Cheers,

Marc

[Vitaly N.]

Works brilliantly, with LDAP_MEMBEROF_FILTER = ".+cn=tacacs.+", number of transactions on LDAP server drops by 80-85%.

I think this is a huge win, thanks for your work on this Marc!

[Marc Huber]

Hi Vitaly,

great, thanks for testing and reporting back!

Cheers,

Marc

> <http://mavis_tacplus-ng_ldap.pl>
> >> b/mavis/perl/mavis_tacplus-ng_ldap.pl
> <http://mavis_tacplus-ng_ldap.pl>

> >> index 264a863..7a4c6c4 100755
> >> --- a/mavis/perl/mavis_tacplus-ng_ldap.pl

> <http://mavis_tacplus-ng_ldap.pl>
> >> +++ b/mavis/perl/mavis_tacplus-ng_ldap.pl
> <http://mavis_tacplus-ng_ldap.pl>

> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and is
> protected by law. If you are not the intended recipient, you should
> delete this message and are hereby notified that any disclosure,
> copying, or distribution of this message, or the taking of any action
> based on it, is strictly prohibited. --
> You received this message because you are subscribed to the Google
> Groups "Event-Driven Servers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to event-driven-ser...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/event-driven-servers/87bb7c8e-377e-45ed-b246-5a0caf7019e4n%40googlegroups.com
> <https://groups.google.com/d/msgid/event-driven-servers/87bb7c8e-377e-45ed-b246-5a0caf7019e4n%40googlegroups.com?utm_medium=email&utm_source=footer>.