tac_plus-ng does not authorise with LDAP backend

[Jan Kayser]

I am running tac_plus-ng with the attached LDAP cfg. Using the admin-rw user, I am logging into the following devices

and apart from Junos which doesn't rely on Tacacs authorisation,

I cannot log into any device (see [nos]-logs.txt).

The debug logs all show an authorisation failure when evaluating the ACLs which seems like the culprit.

When using tactrace.pl or when using the local auth cfg, login works just fine (see ocnos-logs-ok.txt).

Junos (192.168.2.6):

- authentication and "authorisation" works

- Junos doesn't actually use Tacacs authorisation, it applies permissions according to local-user-name, which doesn't appear in the debug logs at all?

- line 235,238 show authorisation fail, why is that?

SR Linux (192.168.2.54):

- authentication and authorisation fail

- line 235,238 show authorisation fail, why is that?

Ocnos (192.168.2.28):

- authentication and authorisation fail

- line 112,115 show authorisation fail, why is that?

ExOS (192.168.2.248):

- authentication and authorisation fail

- line 43,46 show authorisation fail, why is that?

[Marc Huber]

Hi Jan,

On 26.09.2023 02:29, Jan Kayser wrote:
> Junos (192.168.2.6):
> - authentication and "authorisation" works
> - Junos doesn't actually use Tacacs authorisation, it applies
permissions according to local-user-name, which doesn't appear in the
debug logs at all?
> - line 235,238 show authorisation fail, why is that?

good catch, I'll push a fix. Forgot to map "groups" to "member", please
git pull and retry.

diff --git a/tac_plus-ng/config.c b/tac_plus-ng/config.c
index 7519afe..c3a8fac 100644
--- a/tac_plus-ng/config.c
+++ b/tac_plus-ng/config.c
@@ -3739,6 +3739,9 @@ static struct mavis_cond
*tac_script_cond_parse_r(struct sym *sym, tac_realm * r
                if (m->u.s.token == S_clientname)
                    parse_error(sym, "REGEX matching isn't supported
for '%s'", codestring[m->u.s.token]);

+               if (m->u.s.token == S_group)
+                   m->u.s.token = S_member;
+
                m->type = S_regex;
                sym->flag_parse_pcre = 1;
                sym_get(sym);

Thanks,

Marc

[Jan Kayser]

Hi Marc,

The login to any of the devices still fails. I would expect that the admin-rw user matches the following and gets assigned to the profile admin-rw:

(nas == lab && memberof =~ /^cn=ROLE_(ADMIN|DEV)_RW,/)

Alas the authorisation fails...

Regards,

Jan

[Marc Huber]

Hi Jan,

the backend script didn't return a MEMBEROF attribute, causing the
condition to fail.

1061346: 16:59:32.350 52/14b8d526: 192.168.2.28 USER (len: 8): admin-rw
1061346: 16:59:32.350 52/14b8d526: 192.168.2.28 DN (len: 36):
uid=admin-rw,ou=Users,dc=sample,dc=net
1061346: 16:59:32.350 52/14b8d526: 192.168.2.28 SERVERIP (len: 14):
192.168.2.28
1061346: 16:59:32.350 52/14b8d526: 192.168.2.28 REALM (len: 8): port1611
1061346: 16:59:32.350 52/14b8d526: 192.168.2.28 IDENTITY_SOURCE (len: 1): 0

Please double-check that your LDAP server is returning the memberOf
attribute and (if set to a custom value) LDAP_MEMBEROF_REGEX matches
your memberOf values.

Cheers,

Marc

[Jan Kayser]

Hi Marc,

That was the cause, thanks a lot for the hint and the quick bug fix.

Regards,

Jan