cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1719
Views
0
Helpful
2
Replies

ISE 2.x || TACACS+ Authorization through SGT for specific user (local or AD) groups

musultan
Cisco Employee
Cisco Employee

Hello Team,


I’m wondering, rather than using traditional TACACS, if we can use SGTs linked to AD groups that provide access to log into the SDA-based (fabric) or non-SDA based devices? 



In other words, can we implement authorization for management access to NAD devices via TACACS (or Radius) through SGT mapped to AD group?


For Example, if a user connects to a switch port and have the SGT assigned to it. It is also mapped to a AD user group. Can we use this SGT to AD mapping when the same user try to do telnet (or ssh) to NAD device?

 

Any comments or feedback is appreciated.

1 Accepted Solution

Accepted Solutions

Piggybacking on Thomas' response.  Let's say you will authenticate & authorize a user into the SDA fabric overlay and assign an SGT.  In order for that user to reach the SDA underlay he/she is going to need to route leak from VN1 to your global (underlay) table.  Similar situation if needed to get to legacy equipment outside of your fabric.  Meaning you would have to route beyond your fusions.  You have several options to restrict access to your NADs instead of relying on tacacs device admin policy sets with SGT condition.  These options include route leaking control, acls, or something like your generic AD sec group mappings in ISE that would determine your shell profile upon device auth.  And like Thomas mentioned you can also control it via SGTs; User SGT in VN1 can/cant talk to your NAD SGTs.  

 

To fully answer what you are looking for, I am unaware of being able to use an SGT condition for tacacs device admin access policies.

View solution in original post

2 Replies 2

thomas
Cisco Employee
Cisco Employee

There appears to be a lot of confusion about the use of TACACS and RADIUS and software defined segmentation using SGTs.

 

ISE supports both TACACS and RADIUS protocols. TACACS and RADIUS are both authentication and authorization security protocols however they serve totally different purposes and have different authorization policy structures. Both TACACS and RADIUS can rely on an External Identity Store for the authentication and attribution of users and devices. Microsoft Active Directory (AD) is used for this 95+% of the time. 

 

Terminal Access Controller Access Control System (TACACS) is for Command Line Interface (CLI) authorization on a network device. TACACS is used to control Who can do What commands on the CLI. TACACS has nothing to do with the network access authorization and enforcement (using VLANs, ACLs, software-defined segmentation via SGT, etc.) of a user or endpoint onto the network

 

Remote Authentication Dial In User Service (RADIUS) is used for user and/or endpoint authentication & authorization through a network access device (NAD) such as a switch or wireless controller or VPN. A RADIUS authorization of a network session may authorize users or endpoints with a Scalable Group Tag (SGT) classification along with a VLAN, ACL, or other enforcement attributes. Here is an example policy in ISE for assigning a user authenticated with 802.1X to the AD user group "Domain Users" to an SGT named "Employees":image.png

 

 

 

Once that employee is authorized via RADIUS, they may attempt to Telnet (or SSH) to a network device. The ability to use Telnet or SSH from the Employees group to a NetworkDevices group might be blocked entirely by an SGACL so they could not even connect. If it was allowed, they would then be authenticated and authorized for CLI on the network device using the ISE policies for TACACS authentication and authorization which may also use AD groups.

 

I am not aware of a way to use a RADIUS-assigned SGT in ISE (with or without AD involvement) to make a TACACS authorization policy decision.

 

 

Piggybacking on Thomas' response.  Let's say you will authenticate & authorize a user into the SDA fabric overlay and assign an SGT.  In order for that user to reach the SDA underlay he/she is going to need to route leak from VN1 to your global (underlay) table.  Similar situation if needed to get to legacy equipment outside of your fabric.  Meaning you would have to route beyond your fusions.  You have several options to restrict access to your NADs instead of relying on tacacs device admin policy sets with SGT condition.  These options include route leaking control, acls, or something like your generic AD sec group mappings in ISE that would determine your shell profile upon device auth.  And like Thomas mentioned you can also control it via SGTs; User SGT in VN1 can/cant talk to your NAD SGTs.  

 

To fully answer what you are looking for, I am unaware of being able to use an SGT condition for tacacs device admin access policies.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: