Security

Hi Everyone,

I'm working on settings up TACACS for a Niagara Networks device on our network. The TACACS configuration is very minimal in the network device, and there are no roles. As i can see the only valid role is Admin. However we want to be able to deny access to some users. 

I have setup a service with custom TACACS dictionary which allows access to admin based on a AD Group. However if you don't belong to the AD group i do [TACACS Deny profile] enforcement. The issue is that the network device still lets users, even when TACACS Deny is sent back. it seems that it's only Authenticating the user, and allowing them in no mater what the authorization result it.

Is there any way to force a TACACS deny for a user who is valid in AD, but who does not have proper group membership? I tried sending privilege 0, and the user is still accepted. 

Thanks,

_ELiasz

You should have an enforcement policy that sends back the proper privilege for users in AD and then make your default enforcement profile to the "TACACS deny profile" in that enforcement policy.

That is what i have configured. However, it doesn't seem to deny the users.

I get a service not enabled error when using the [TACACS Deny Profile]. I created a new profile with privilage level 0 and using the correct TACACS dictionary, however it still allows access. 

In the logs it appears that authenticaiton is allowed, an no matter what authorization is send back, the NAD allows user in with Admin role. 

If you have Authentication set as AD, and the user is valid in AD, authentication will be successful, in the sense that the user/pass combination is valid.

You would deny access in the Enforcement Profile as described before. If Deny doesn't work, have you tried sending back Priv1 for Read-Only and see if it accepts that?

I would also consult the Niagara user-guide and see if there is a TACACS setup section, which includes the values to be sent back.

The Niagara Users Guide TACACS section is a half page, and says here is where you configure the IP and preshared key, so unfortunately not helpful.

I did create a custom Deny profile with the correct dictionary, however it is ignored. I send back priv 0, or priv 1, and i still get access with admin role. I think it only look for authentication response, not authorization values.

I worked with TAC and we did figure out how to do this. Basically we needed to replicate the auth source, and in the user query add &(memberof=CN=XXX,OU=XYZ...DC=com). So basically the user lookup only succeeds if the user is part of the required group. It's not pretty, and it doesn't support nested groups, but at least not it denies the users correctly.

Thanks for the ideas everyone.

_ELiasz