TACACs and local users with the same user name but different permissions

[padma]

Hi,

We have a user “TestRole” created on tacacs server and also on local.

At TACACs, “TestRole” has read permissions. At Local “TestRole” user has read-write permissions.

Authentication order is ‘tacacs local’.

When we login with user ‘TestRole’, the TACACs servers was contacted, and the login was success for TACACS user. But the permissions granted for this user is read and write. Which is wrong, we expect the permissions to be read only. This might be because, the nacm is appending both the permissions.

When we remove the local user ‘TestRole’, the then TACACs user ‘TestRole’ gets Read only permissions.

Please let me know if there is a way to assign permissions based on the TACACS user or based on the type of authentication.

Thanks,

Padma

[mvf]

I’m assuming that by “tacacs” authentication method you mean an external authentication implemented via a TACACS client that gets user attributes from the TACACS server and responses with user groups to ConfD.

Local NACM group configuration must always be used, regardless of what authentication method was used. The groups assigned externally areused in addition to that, and only if /nacm/enable-external-groups has not been set to false. This is a requirement of RFC 8341. In your case it means that if the user TestRole is locally configured as member of the group admin, the group admin is used in addition to any groups returned by the external authentication script.

I see two options:

1. Make sure that externally authenticated users do not have local group assignments (I’d actually be curious to hear a use-case for having that).

2. Use “negative” rule-lists/rules. For example, if your user TestRole is externally assigned the group test and all members of that group are supposed to have read-only access to the configuration subtree under /config-root, have a rule-list instance for the group test whose rules deny write access to /config-root. Something like this:

   nacm rule-list deny-tests
    group [ test ]
    rule no-config-root
     path   /config-root
     access-operations create,update,delete;
     action deny
    !
   !
   

   If that rule-list instance comes before any instances that grant write access to admin, write operations are denied. I suspect that this approach might not scale well, in general it might require too many rules; but perhaps it works in your case.

[padma]

Thanks for the reply.
option 2 is ruled out,that’s a not workable solution for us.

Regarding option 1, what you suggest is not to have the same user name in both tacacs and local with different group assignments(which is the issue that we are facing right now). Please confirm. But since we can’t restrict this type of configuration, this might be security loop hole.

regarding /nacm/enable-external-groups setting to ‘false’, this completely ignores the use of external groups. This is not what we want. We want the external groups to be considered and provide the right type of permissions based on the external group when external user is logged in.

If there is no group assigned to the external user, is there a way to set default role to the external user locally?

[mvf]

@padma

Regarding option 1, what you suggest is not to have the same user name in both tacacs and local with different group assignments(which is the issue that we are facing right now). Please confirm. But since we can’t restrict this type of configuration, this might be security loop hole.

Yes, that’s what I meant. And yes, I agree - keeping locally configured user permissions while TACACS authentication and authorization is assumed creates kind of a security hole, so you should better avoid it.

A lot of stuff can be done dynamically when needed, but it requires quite a bit more code. The most extreme option is authorization callbacks - your code can permit or deny every single user operation, but as written in the documentation, “using these callbacks can thus have a significant performance impact”.

An option with negligible performance impact but still requiring quite some effort is that your external authentication executable reconfigures NACM just as the user is logging in - the user session’s permissions are read from NACM and cached as the session starts and no further NACM configuration changes can affect that particular session. So before the external authentication sends “success” response, it can reconfigure NACM to whatever is needed and the configuration is used for that new session.

(Disclaimer: I have not tested that last variant; I saw something similar but even more complex in production, but I believe this simple version can work too.)