cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
27013
Views
24
Helpful
16
Replies

Cisco ISE with TACACS+ and RADIUS both?

RSundstrom
Level 1
Level 1

Hello,

I am initiating wired authentication on an existing network using Cisco ISE. I have been studying the requirements for this. I know I have to turn on RADIUS on the Cisco switches on the network. The switches on the network are already programmed for TACACS+. Does anybody know if they can both operate on the same network at the same time?

Bob

4 Accepted Solutions

Accepted Solutions

Jatin Katyal
Cisco Employee
Cisco Employee

I guess tacacs is configured (with ACS 4.x or 5.x) for device administration via telnet/ssh and now you need radius (with radius) for 802.1x authentication. Yes they can both operate on the same network at the same time.

~BR
Jatin Katyal

**Do rate helpful posts**

~Jatin

View solution in original post

msonnie
Level 1
Level 1

Hello Robert,

I believe NO, they both won't work together as both TACACS and Radius are different technologies.

It's just because that TACACS encrypts the whole message and Radius just the password, so I believe it won't work.

For your reference, I am sharing the link for the difference between TACACS and Radius.

http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080094e99.shtml

Moreover, Please review the information as well.

Compare TACACS+ and RADIUS

These sections compare several features of TACACS+ and RADIUS.

UDP and TCP
RADIUS uses UDP while TACACS+ uses TCP. TCP offers several advantages over UDP. TCP offers a connection-oriented transport, while UDP offers best-effort delivery. RADIUS requires additional programmable variables such as re-transmit attempts and time-outs to compensate for best-effort transport, but it lacks the level of built-in support that a

TCP transport offers:

TCP usage provides a separate acknowledgment that a request has been received, within (approximately) a network round-trip time (RTT), regardless of how loaded and slow the backend authentication mechanism (a TCP acknowledgment) might be.

TCP provides immediate indication of a crashed, or not running, server by a reset (RST). You can determine when a server crashes and returns to service if you use long-lived TCP connections. UDP cannot tell the difference between a server that is down, a slow server, and a non-existent server.

Using TCP keepalives, server crashes can be detected out-of-band with actual requests. Connections to multiple servers can be maintained simultaneously, and you only need to send messages to the ones that are known to be up and running.

TCP is more scalable and adapts to growing, as well as congested, networks.

Packet Encryption
RADIUS encrypts only the password in the access-request packet, from the client to the server. The remainder of the packet is unencrypted. Other information, such as username, authorized services, and accounting, can be captured by a third party.

TACACS+ encrypts the entire body of the packet but leaves a standard TACACS+ header. Within the header is a field that indicates whether the body is encrypted or not. For debugging purposes, it is useful to have the body of the packets unencrypted. However, during normal operation, the body of the packet is fully encrypted for more secure communications.

Authentication and Authorization
RADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contain authorization information. This makes it difficult to decouple authentication and authorization.

TACACS+ uses the AAA architecture, which separates AAA. This allows separate authentication solutions that can still use TACACS+ for authorization and accounting. For example, with TACACS+, it is possible to use Kerberos authentication and TACACS+ authorization and accounting. After a NAS authenticates on a Kerberos server, it requests authorization information from a TACACS+ server without having to re-authenticate. The NAS informs the TACACS+ server that it has successfully authenticated on a Kerberos server, and the server then provides authorization information.

During a session, if additional authorization checking is needed, the access server checks with a TACACS+ server to determine if the user is granted permission to use a particular command. This provides greater control over the commands that can be executed on the access server while decoupling from the authentication mechanism.

Multiprotocol Support
RADIUS does not support these protocols:

AppleTalk Remote Access (ARA) protocol

NetBIOS Frame Protocol Control protocol

Novell Asynchronous Services Interface (NASI)

X.25 PAD connection

TACACS+ offers multiprotocol support.

Router Management
RADIUS does not allow users to control which commands can be executed on a router and which cannot. Therefore, RADIUS is not as useful for router management or as flexible for terminal services.

TACACS+ provides two methods to control the authorization of router commands on a per-user or per-group basis. The first method is to assign privilege levels to commands and have the router verify with the TACACS+ server whether or not the user is authorized at the specified privilege level. The second method is to explicitly specify in the TACACS+ server, on a per-user or per-group basis, the commands that are allowed.

Interoperability
Due to various interpretations of the RADIUS Request for Comments (RFCs), compliance with the RADIUS RFCs does not guarantee interoperability. Even though several vendors implement RADIUS clients, this does not mean they are interoperable. Cisco implements most RADIUS attributes and consistently adds more. If customers use only the standard RADIUS attributes in their servers, they can interoperate between several vendors as long as these vendors implement the same attributes. However, many vendors implement extensions that are proprietary attributes. If a customer uses one of these vendor-specific extended attributes, interoperability is not possible.

Traffic
Due to the previously cited differences between TACACS+ and RADIUS, the amount of traffic generated between the client and server differs. These examples illustrate the traffic between the client and server for TACACS+ and RADIUS when used for router management with authentication, exec authorization, command authorization (which RADIUS cannot do), exec accounting, and command accounting (which RADIUS cannot do).

View solution in original post

msonnie
Level 1
Level 1

Moreover, ISE won't understand TACACS... Yet..!!! Which ( TACACS ) would be added in ISE in ISE 2.0, to be released somewhere in the 2nd Half of Q'14.

View solution in original post

I'm not sure what is your take away from this thread however, I'd like to summerize that if your network devices are already configured with tacacs ( other than ISE that supports TACACS protocol) for managing network devices and now if you are planning to implement ISE with radius protocol for wired/wireless 802.1x authentication. This is very much possible.

~BR
Jatin Katyal

**Do rate helpful posts**

~Jatin

View solution in original post

16 Replies 16

Jatin Katyal
Cisco Employee
Cisco Employee

I guess tacacs is configured (with ACS 4.x or 5.x) for device administration via telnet/ssh and now you need radius (with radius) for 802.1x authentication. Yes they can both operate on the same network at the same time.

~BR
Jatin Katyal

**Do rate helpful posts**

~Jatin

msonnie
Level 1
Level 1

Hello Robert,

I believe NO, they both won't work together as both TACACS and Radius are different technologies.

It's just because that TACACS encrypts the whole message and Radius just the password, so I believe it won't work.

For your reference, I am sharing the link for the difference between TACACS and Radius.

http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080094e99.shtml

Moreover, Please review the information as well.

Compare TACACS+ and RADIUS

These sections compare several features of TACACS+ and RADIUS.

UDP and TCP
RADIUS uses UDP while TACACS+ uses TCP. TCP offers several advantages over UDP. TCP offers a connection-oriented transport, while UDP offers best-effort delivery. RADIUS requires additional programmable variables such as re-transmit attempts and time-outs to compensate for best-effort transport, but it lacks the level of built-in support that a

TCP transport offers:

TCP usage provides a separate acknowledgment that a request has been received, within (approximately) a network round-trip time (RTT), regardless of how loaded and slow the backend authentication mechanism (a TCP acknowledgment) might be.

TCP provides immediate indication of a crashed, or not running, server by a reset (RST). You can determine when a server crashes and returns to service if you use long-lived TCP connections. UDP cannot tell the difference between a server that is down, a slow server, and a non-existent server.

Using TCP keepalives, server crashes can be detected out-of-band with actual requests. Connections to multiple servers can be maintained simultaneously, and you only need to send messages to the ones that are known to be up and running.

TCP is more scalable and adapts to growing, as well as congested, networks.

Packet Encryption
RADIUS encrypts only the password in the access-request packet, from the client to the server. The remainder of the packet is unencrypted. Other information, such as username, authorized services, and accounting, can be captured by a third party.

TACACS+ encrypts the entire body of the packet but leaves a standard TACACS+ header. Within the header is a field that indicates whether the body is encrypted or not. For debugging purposes, it is useful to have the body of the packets unencrypted. However, during normal operation, the body of the packet is fully encrypted for more secure communications.

Authentication and Authorization
RADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contain authorization information. This makes it difficult to decouple authentication and authorization.

TACACS+ uses the AAA architecture, which separates AAA. This allows separate authentication solutions that can still use TACACS+ for authorization and accounting. For example, with TACACS+, it is possible to use Kerberos authentication and TACACS+ authorization and accounting. After a NAS authenticates on a Kerberos server, it requests authorization information from a TACACS+ server without having to re-authenticate. The NAS informs the TACACS+ server that it has successfully authenticated on a Kerberos server, and the server then provides authorization information.

During a session, if additional authorization checking is needed, the access server checks with a TACACS+ server to determine if the user is granted permission to use a particular command. This provides greater control over the commands that can be executed on the access server while decoupling from the authentication mechanism.

Multiprotocol Support
RADIUS does not support these protocols:

AppleTalk Remote Access (ARA) protocol

NetBIOS Frame Protocol Control protocol

Novell Asynchronous Services Interface (NASI)

X.25 PAD connection

TACACS+ offers multiprotocol support.

Router Management
RADIUS does not allow users to control which commands can be executed on a router and which cannot. Therefore, RADIUS is not as useful for router management or as flexible for terminal services.

TACACS+ provides two methods to control the authorization of router commands on a per-user or per-group basis. The first method is to assign privilege levels to commands and have the router verify with the TACACS+ server whether or not the user is authorized at the specified privilege level. The second method is to explicitly specify in the TACACS+ server, on a per-user or per-group basis, the commands that are allowed.

Interoperability
Due to various interpretations of the RADIUS Request for Comments (RFCs), compliance with the RADIUS RFCs does not guarantee interoperability. Even though several vendors implement RADIUS clients, this does not mean they are interoperable. Cisco implements most RADIUS attributes and consistently adds more. If customers use only the standard RADIUS attributes in their servers, they can interoperate between several vendors as long as these vendors implement the same attributes. However, many vendors implement extensions that are proprietary attributes. If a customer uses one of these vendor-specific extended attributes, interoperability is not possible.

Traffic
Due to the previously cited differences between TACACS+ and RADIUS, the amount of traffic generated between the client and server differs. These examples illustrate the traffic between the client and server for TACACS+ and RADIUS when used for router management with authentication, exec authorization, command authorization (which RADIUS cannot do), exec accounting, and command accounting (which RADIUS cannot do).

msonnie
Level 1
Level 1

Moreover, ISE won't understand TACACS... Yet..!!! Which ( TACACS ) would be added in ISE in ISE 2.0, to be released somewhere in the 2nd Half of Q'14.

Thank you Jatin and Mohit,

Your posts answered my questions.

Bob

I'm not sure what is your take away from this thread however, I'd like to summerize that if your network devices are already configured with tacacs ( other than ISE that supports TACACS protocol) for managing network devices and now if you are planning to implement ISE with radius protocol for wired/wireless 802.1x authentication. This is very much possible.

~BR
Jatin Katyal

**Do rate helpful posts**

~Jatin

I have found out what I needed in this situation. That is that TACACS+ and RADIUS can exist on the same network without causing problems.

I understand that ISE uses only RADIUS at this point. We have other devices that are using TACACS+ currently.

I am new to the Cisco Forum and am learning the details of this site.

Thanks for your understanding and help,

Bob

you got it right

~BR
Jatin Katyal

**Do rate helpful posts**

~Jatin

Hello,

We could not find information about the ISE roadmap regarding Tacacs support other than this post 2 years ago. Currently latest version of ISE is 1.3,  is ISE Tacacs still on the roadmap for 2.0?  If currently the date is specified,  will 2.0 (or the Tacacs support) be released?

Best REgards,

Here you go!

 

https://supportforums.cisco.com/discussion/12462501/ise-20-and-tacacs

 

Please Rate Helpful posts and mark this question as answered if, in fact, this does answer your question.  Otherwise, feel free to post follow-up questions.

Charles Moreton

Thanks Charles,

This was what we were searching, so it is not ISE 2.0 but 1.5 that has changed

 

Best Regards,

Angus Bishop
Level 1
Level 1

Hey jatin / robert ,

Can you please let me know how to do both Tacacs and Radius in switch when using ISE for client authentication and authorization

When i tried configuring a test switch only with Radius protocol my network worked fine as expected with ISE  .

But the same config when i tried in the production switch with Tacacs running  its not working as expected .

Can you please help me to figure out the issue

Test Switch config

--------------------------------

aaa new-model

!

!

aaa authentication login default local

aaa authentication dot1x default group radius

aaa authorization network default group radius

aaa accounting update periodic 5

aaa accounting dot1x default start-stop group radius

!

!

aaa server radius dynamic-author

client 10.242.aa.bb server-key 7 070C285F4D06101612

ip device tracking

epm logging

dot1x system-auth-control

interface GigabitEthernet1/0/1

switchport access vlan xxx

switchport mode access

switchport voice vlan yyy

ip access-group ACL-DEFAULT in

srr-queue bandwidth share 1 25 50 25

priority-queue out

authentication event fail action next-method

authentication host-mode multi-auth

authentication order mab

authentication priority  mab

authentication port-control auto

authentication violation restrict

mab

snmp trap mac-notification change added

snmp trap mac-notification change removed

mls qos vlan-based

dot1x pae authenticator

dot1x timeout tx-period 10

spanning-tree portfast

spanning-tree guard root

!

ip http server

ip http secure-server

!

ip radius source-interface Vlan305

logging host 10.242.aa.bb transport udp port 20514

!

radius-server attribute 6 on-for-login-auth

radius-server attribute 8 include-in-access-req

radius-server attribute 25 access-request include

radius-server dead-criteria time 30 tries 3

radius-server host 10.242.a.bb auth-port 1812 acct-port 1813 test username ise-test key 7 13061E0108030D392E

         radius-server vsa send accounting

radius-server vsa send authentication

mac address-table notification change

mac address-table notification mac-move

Please let me know how to configure the above config in a switch which is already running TACACS

Regards

Angus

As I informed before as well...

ISE won't understand TACACS... Yet..!!! Which ( TACACS ) would be added in ISE in ISE 2.0, to be released somewhere in the 2nd Half of Q'14.

I want to do dot1x and  mab using radius (ise) and the Tacacs for network device authentication ....

Is this posible .

I think we can do this by creating a seperate group for Radius . Am not sure since i am new to this ...

This can only be possible if you use ISE as radius server for MAB/Dot1x and ACS 4.x or ACS 5.x as a tacacs server for network device authentication.

~BR
Jatin Katyal

**Do rate helpful posts**

~Jatin
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: