- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2020 03:19 AM
Hi all,
I have this situation where I need to authenticate a particular user on Nexus devices via ISE, but the user should not be permitted to do anything else on the device.
I have configured a new Tacacs Profile with the following:
Common Task Type -> Nexus
Set Attribute as: Optional
Network Role --> None
VDC Role --> None
Custom Attribures
Mandatory priv-lvl:0
Mandatory max_priv_lvl:0
I also created a TACACS Command Set that denies any configure and any show commands.
In the Policy Sets for the explicit user, when trying to access the Nexus Devices, the authorization policy is tied with the above command sets and the profile.
The end result is what I am expecting... user can log in and nothing can be run. Is this the correct way to go about it or do I need to do something different. To be frank I got a bit confused with the Profile settings...
Thank you in advance,
Katerina
Solved! Go to Solution.
- Labels:
-
Identity Services Engine (ISE)
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2020 03:56 AM
Command authorization via Tacacs is allowed on the Nexus but Command authorization disables user role based authorization control (RBAC), including the default roles. As you are configuring command set, I believe below config is there on your Nexus switch:
—aaa authorization commands default <ISE>
—aaa authorization config-commands default <ISE>
In such case, this config, looks good to me, although I don't see the need for custom attributes.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2020 03:35 AM
That looks pretty good to me. So in effect, this is like a TCP keep alive for Nexus to check whether TACACS+ server is still alive?
Why is this feature so important? If you have two TACACS+ servers defined in your config Group, then surely that would suffice? If a request to server 1 times out after 3 attempts, then use server 2, etc.
The keepalive feature might make things happen a bit faster/deterministic - but if it causes your auditors to have a coronary, then you could probably leave it out.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2020 04:47 AM
Hi Arne,
this is indeed a sort of keepalive for the Nexus... If the auditors don't like it, and aren't satisfied with our explanations, then we will live it out. If we can keep it though and it works, even better!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2020 03:56 AM
Command authorization via Tacacs is allowed on the Nexus but Command authorization disables user role based authorization control (RBAC), including the default roles. As you are configuring command set, I believe below config is there on your Nexus switch:
—aaa authorization commands default <ISE>
—aaa authorization config-commands default <ISE>
In such case, this config, looks good to me, although I don't see the need for custom attributes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2020 04:38 AM - edited 05-14-2020 04:28 AM
TelltheBell wrote:Command authorization via Tacacs is allowed on the Nexus but Command authorization disables user role based authorization control (RBAC), including the default roles. As you are configuring command set, I believe below config is there on your Nexus switch:
—aaa authorization commands default <ISE>
—aaa authorization config-commands default <ISE>
In such case, this config, looks good to me, although I don't see the need for custom attributes.
Thank you for sharing article and information. this is very helpful for beginner.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2020 04:52 AM
So I understand that I could remove the priv-level etc altogether and everything would still be ok, since I am limiting access through the command sets.
