[tacacs]: skip accessing tacacs servers for local non-tacacs users

[renukamanavalan]

This helps use the legacy passwd file for user info and go to tacacs only if not found.
This means, we never contact tacacs for local users like "admin".
This isolates local users from any issues with tacacs servers.
W/o this fix, the sudo commands by local users could take * seconds, if the tacacs servers are unreachable.

- What I did
Switched order of user lookup to "compat" first, followed by "tacplus".

- How I did it

- How to verify it
Configure properly for tacacs+ login, with exception of server-IP, where you put an unreachable/non-existing.
login as admin and try "time sudo ls"

This would take roughly * <tacacs timeout -- which defaults to 5> seconds.

With this fix, the "sudo" will work fine

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[lguohan]

looks like #2163 changed this deliberately.

[lguohan]

without #2163, if user is already in passwd file nss will not even communicate with tacacs. This is to address the scenario of user permission change

[renukamanavalan]

There does not seems to be a detailed explanation of the bug in the PR #2163.

In short:
When a TACACS user login, indeed a passwd entry gets created, but with a locked passwd. This implies that when the same TACACS user logs in, he can't get in w/o reaching tacacs server.

But say a TACACS user is logged in, and then his credentials are removed from TACACS servers, it would not affect his current session. But he can't create anymore new sessions.

So this restricts the nss access to only getting user info and nothing more.

Hence compat first and TACACS next, should not affect the level of security in any way,

Later when we move on to controlling authorizations, I believe this, still would not impact as its impact is restricted to getpwnam, getpwent and related functions, with source of info from passwd file only.

[lguohan]

the scenario is that user change from ro to rw, if we put compat first, will the user privilege gets updated after he changed from ro to rw on the tacacs side.

[lguohan]

I have this question, why do you choose to compare the gecos? why not compare the group name of the tacacs user? it is going to be either remote_user or remote_user_su.

[lguohan]

one more comment

[renukamanavalan]

The strings "remote_user" & "remote_user_su" are not names of groups, but used to set pw_gecos (Full name) of the user.

The read-only users (privilege level = 1) get the gid as "100", which is users:x:100:user_ro and rw users (privilege level = 15) gets gid=1000 which is admin:x:1000: as primary group and "sudo,docker" as secondary groups.