cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7343
Views
1
Helpful
4
Replies

ISE 2.1 - TACACS/Device Admin - Authorization rule not working

IP Team
Level 1
Level 1

Hi All,

I’m hoping you can help with an issue I have with TACACS Device Admin on ISE 2.1

In Device Administration > Device Admin Policy Sets , I’ve created a new policy which has:

  • Status: enabled, conditions: device type – allow all device types
  • An Authentication rule that checks users based on an external AD source – this works fine as indicated by the TACACS live log. Allow protocols: default device admin.
  • An Authorization rule which again checks users based on an external AD group then applies the following elements with an ‘AND’ statement:
    1. Command set: permit – ping, show, traceroute commands with all arguments ( using * ). Permit ‘exit’.
      • I have not ticked the box ‘permit any command that is not listed below’, so I have not needed use a deny statement.
    2. TACACS profile: In common tasks, type ‘Shell’ only two options selected, a default and maximum priviledge both set to ‘1’.
  • There are no global/local exception rules.

The TACACS live log shows that authentication passed with the intended authentication rule (checking through AD), it also shows the correct

Authorization rule being called upon (which also checks a user based on an AD group) however the only thing working from that is when a user

logs in the default priviledge is set to 1.

Commands are not restricted based on the command set and using the enable command the user can still go into priviledge level 15.

It seems somehow the Authorization rule (command set/profile) is not being utilized fully?

Essentially I just need the authorization rule to restrict the users within that specific AD group to have access to priviledge level 1, and only able to execute read only commands.

Regards

Shams

1 Accepted Solution

Accepted Solutions

hslai
Cisco Employee
Cisco Employee

ISE Device Administration (TACACS+) might help you.

Your configuration seems missing "aaa authentication enable ..."

Once that in, we would expect it failing right after issuing "enable". Below is a result I got in our lab setup:

Screen Shot 2016-10-06 at 7.41.32 PM.png

Screen Shot 2016-10-06 at 7.41.42 PM.png

Other Attributes

...

Screen Shot 2016-10-06 at 7.42.06 PM.png

View solution in original post

4 Replies 4

gbekmezi-DD
Level 5
Level 5

Can you share the aaa configuration from your nad?

Warning: I either dictated this to my device, or typed it with my thumbs. Erroneous words are a feature, not a typo.

Hi George,

Thanks for your reply - config wise:

aaa authentication login Use_Tacacs group tacacs+ line

aaa authentication login No_Tacacs line

aaa authorization exec Use_Tacacs group tacacs+ if-authenticated none

aaa authorization commands 1 Tacacs_Auth group tacacs+ if-authenticated none

aaa authorization commands 15 Tacacs_Auth group tacacs+ if-authenticated none

line vty 0 4

exec-timeout 5 0

password .......

authorization commands 1 Tacacs_Auth

authorization commands 15 Tacacs_Auth

authorization exec Use_Tacacs

logging synchronous

login authentication Use_Tacacs

As an update I've got the command restrictions to work, by taking off    ' * '  in the arguments field. I put a star in there thinking it will include all subcommands which i can use with a permit. I took it off and the permit command was working as expected. What isn't working is if I put 'deny_always' (or deny) under the Grant column, and 'enable' under the Command column (with or without an argument).

Although command restrictions are working the user can still go into priviledged exec mode/15, even if default privilege & maximum privilege is set to 1 on the tacacs profile.

In the detailed tacacs log I get this when logging in:

Authorization Attributes

All Request Attribues  
All Response Attribues priv-lvl=1

Other Attributes

Response {Author-Reply-Status=PassAdd; AVPair=priv-lvl=1; }

hslai
Cisco Employee
Cisco Employee

ISE Device Administration (TACACS+) might help you.

Your configuration seems missing "aaa authentication enable ..."

Once that in, we would expect it failing right after issuing "enable". Below is a result I got in our lab setup:

Screen Shot 2016-10-06 at 7.41.32 PM.png

Screen Shot 2016-10-06 at 7.41.42 PM.png

Other Attributes

...

Screen Shot 2016-10-06 at 7.42.06 PM.png

Excellent thanks very much, fixed it!