Authenticating against RADIUS *AND* TACACS

[aho]

G'day...

Toys:

Cisco Secure ACS 3.2

Cisco 1242 Access Points

I want to authenticate spectralink phones via LEAP (Radius Aironet) and IT staff logging onto the CLI via TACACS+, all off the same ACS Server.

The only way I have gotten this to work is to setup TWO Network Device Groups, and add the access point in TWICE (with different unique hostnames). One authenticating RADIUS, and the other profile authenticating TACACS.

Is this the right way to go about it? Why can't I pick two authentication methods under the one AAA Client profile?

Cheers,

Andrew.

[a.kiprawih]

Hi,

The AAA client hostname configured in Cisco Secure ACS is not required to match the hostname configured on a network device, you can assign any name. What is important is the IP Address to allow the device and ACS to communicate via each AAA protocol.

If your device need to use both TACACS+ and RADIUS to authenticate 2 different users, then your method is right. This is because a device with same name cannot use both AAA methods to authenticate users - different operation. You have to use 2 different names, but running on the same IP on both TACACS+ and RADIUS.

I am using the same approach to authenticate remote access clients and network admin in my Access Server.

Rgds,

AK

[aho]

Thanks for that...

Sounds like the way I did it is how it's supposed to be done. Just checking that there wasn't a more elegant and "neater" solution than having two entries for the one AAA client!

Thanks again :)

Andrew.

[darpotter]

This is indeed the way it should be done - in that sense you can think of RADIUS & TACACS+ as being two interfaces on the same same device.

Many people use a naming convention (eg device_R or _T) to distinquish between the two.

The trick is how to stop a non-admin user from being able login via T+ onto the device CLI ;)

Darran

[ben.bass0]

"The trick is how to stop a non-admin user from being able login via T+ onto the device CLI ;)"

I'm just implementing aaa in our environment and have run into this issue. Is there a way in ACS to control this problem? I had to add the following authorization statement to the switch plus explicitly deny all shell access to unnecessary groups to prevent my active directory accounts from being able to log in...

aaa authorization exec default group tacacs local

[darpotter]

Hi, yes it can be done.

The key is that ACS has two types of NAR:

IP Based NAR - used mainly by T+ (L3)

CLI/DNIS NAR - used mainly by RADIUS (L2)

The names were poorly chosen as they are in effect layer 2 and layer 3 filters.

So in your non-admin groups add an IP NAR that denies everything or permits nothing. This will prevent a dial/wlan/vpn/etc user being able to login a device

et voila :)

Darran

[jvr775]

Darran,

In the instance of using group mapping to Active directory for Wireless user authentication, should it be the same to Deny the non-admin groups via CLI NAR to the all AAA Clients dropdown? Or should it be deny them via IP Based NAR to the AAA Clients dropdown.