Membership of groups (nesting) not finding service junos-exec

[barreljan]

Hi there,

I have been battleling for hours now to finally figure out where it stops working and most important how it does work (for me). I'm using the following

centos7

tac_plus version 202104181633/PCRE

windows ad through the mavid ldap backend

The following config is applied:

id = tac_plus {
        mavis module = external {
                setenv LDAP_SERVER_TYPE = "microsoft"
                setenv LDAP_HOSTS = "192.168.1.101:3268"
                setenv LDAP_SCOPE = sub
                setenv LDAP_BASE = "dc=netwerk,dc=local"
                setenv LDAP_FILTER = "(&(objectclass=user)(sAMAccountName=%s))"
                setenv LDAP_USER = "sa_tacauth@mydomain"
                setenv LDAP_PASSWD = "Mypassword"
                setenv AD_GROUP_PREFIX = ""
                setenv UNLIMIT_AD_GROUP_MEMBERSHIP = 1
                setenv EXPAND_AD_GROUP_MEMBERSHIP = 1
                # setenv REQUIRE_TACACS_GROUP_PREFIX = 1
                # setenv USE_TLS = 0
                exec = /usr/local/lib/mavis/mavis_tacplus_ldap.pl
        }

        login backend = mavis
        user backend = mavis
        pap backend = mavis
        skip missing groups = yes

        host = global {
                # Default key
                address = 0.0.0.0/0
                prompt = "Tacacs Authentication\n"
                key = S3cretpass
                enable 15 = clear s3creten4ble
        }

        # Cisco
        group = cisco {
                enable = login
        }
        # Cisco levels
        group = cisco-read-only {
                member = cisco
                service = shell {
                        default command = deny
                        default attribute = permit
                        set priv-lvl = 15
                        cmd = show { permit .* }
                        cmd = who { permit .* }
                        cmd = login { permit .* }
                        cmd = send { permit .* }
                }
        }
        group = cisco-read-write {
                member = cisco
                service = shell {
                        default command = permit
                        default attribute = permit
                        set priv-lvl = 15
                }
        }

        # Juniper
        group = juniper {
                service = junos-exec {
                        set idletime = 5
                        set timeout = 60
                }
        }
        # Juniper levels
        group = juniper-superuser {
                member = juniper
                service = junos-exec {
                        set local-user-name = usuper
                }
        }
        group = juniper-operator {
                member = juniper
                service = junos-exec {
                        set local-user-name = uops
                }
        }
        group = read-only {
                member = cisco-read-only@global
                member = juniper-operator@global
                member = brocade-level_5@global
                member = extreme-level_15_support@global
        }

        group = read-write {
                member = cisco-read-write@global
                member = juniper-superuser@global
                member = brocade-level_0@global
                member = extreme-level_15@global
        }
        group = Device_Authentication_NOC {
                member = read-write
        }

I am connecting as a user, directly member of ' Device_Authentication_NOC' in the AD.

Now, I have some (as you can see) some other groups as well that in my opion do not matter, however the problem is that when connecting to a JunOS device the junos-exec service is not picked up in the 'juniper-superuser' group, nor the 'juniper-operator' group. When debugging the tac_plus output, no output is there in the authorization part about "local-user-name=usuper"

When I shift the rule:

                member = juniper-superuser@global

To the level of the group 'Device_Authentication_NOC' it suddenly works. The debugging now show the stuff I want to see:

13717: 16:23:51.081 0/2fc87162: 192.168.50.230 nas:absent srv:idletime=5 -> add idletime=5 (k)
13717: 16:23:51.081 0/2fc87162: 192.168.50.230 nas:absent srv:local-user-name=usuper -> add local-user-name=usuper (k)
13717: 16:23:51.081 0/2fc87162: 192.168.50.230 nas:absent srv:timeout=60 -> add timeout=60 (k)

Why does this happen? A level deeper and the whole junos-exec parts are skipped. Not the local-username, nor the timeouts. Debug logs tell everything is fine apart from not mentioning the local-username and the Junos device never receiving the local username...

The Cisco part is working fine. Same style of membership througout the config and that all works.

As I do have the workaround here, but it still bugs me. This is a small part of group definitions yet to come, so the enable a new department with just a 'readonly' save a lot of configuration lines and saves me from finding out why a department has privilege issues somewhere.

What am I missing here? Any ideas?

[Marc Huber]

Hi,

On 23.09.21 16:45, barreljan wrote:
>         group = read-only {
>                 member = cisco-read-only@global
>                 member = juniper-operator@global
>                 member = brocade-level_5@global
>                 member = extreme-level_15_support@global
>         }

overlapping group memberships plainly aren't supported. You can either
merge those services into one group or use dedicated NAS device groups
instead of "global".

Cheers,

Marc

[barreljan]

Thanks for the swift reply. It does makes sense as I already noticed that somehow the cisco group needed to be 'on top'... Strange that it somehow does work on a certain level though.

What I have come up to now is this. Basically it defaults to the hosts group "global"and vendors with a different approach (say using the same service shell but a different priv-lvl) in a seperate group.

        host = global {
                # Default key
                address = 0.0.0.0/0
                prompt = "Tacacs Authentication\n"
                key = S3cretpass
                enable 15 = clear s3creten4ble

        host = other_devs {
               address = 10.1.1.0/24

                prompt = "Tacacs Authentication\n"

               key = kilroywashere

        group = read-write_global {
                # For Cisco
                enable = login
                # For Cisco and Extreme

                service = shell {
                        default command = permit
                        default attribute = permit
                        set priv-lvl = 15
                }

                # For Juniper

                service = junos-exec {
                        set local-user-name = usuper

                        set idletime = 5
                        set timeout = 60
                }

                # For Brocade
                service = exec {
                        # 0 = full access (super user)
                        set priv-lvl = 0
                }
        }
        group = read-write_somevendor {

                # dummy group

                service = shell {
                          # lvl 5 = god-mode
                          set priv-lvl = 5
                }
        }

        group =  Device_Authentication_NOC {
                member = read-write_global
                member = read-write_somevendor@other_devs
        }

Is this the/a correct path I am following?

Op do 23 sep. 2021 om 19:19 schreef Marc Huber <marc.j...@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 on the web visit https://groups.google.com/d/msgid/event-driven-servers/77502825-546f-fbef-4a10-786a2a634bff%40googlemail.com.

[Marc Huber]

Hi,

On 24.09.21 08:58, barreljan wrote:
> Thanks for the swift reply. It does makes sense as I already noticed
> that somehow the cisco group needed to be 'on top'... Strange that it
> somehow does work on a certain level though.
>
> What I have come up to now is this. Basically it defaults to the hosts
> group "global"and vendors with a different approach (say using the
> same service shell but a different priv-lvl) in a seperate group.

...

> Is this the/a correct path I am following?

yes, it is. Merging the services by group is the way to go.

Cheers,

Marc