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: