AAA TACACS+ authentication of IOS HTTP service

gkuzmowycz · ‎07-26-2010

I am having difficulty with TACACS+ authentication to the HTTP service running on IOS-based switches.

The TACACS+ server is Secure ACS Express (the appliance) running Build 5.0.0.18.

The IOS configuration is:

aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization console
aaa authorization exec default group tacacs+ if-authenticated
aaa session-id common
ip http authentication aaa login-authentication default

ip tacacs source-interface Loopback0
tacacs-server host nnn.nnn.nnn.nnn
tacacs-server directed-request
tacacs-server key 7 keyhash

This works as expected against 38xx routers running IOS 12.4(3g). It fails against 3560 switches running IOS 12.2(40)SE or 4507 switches running IOS 12.2(31)SGA10, even though the TACACS+ server's authentication report indicates that it sent a "Passed", and the switch's debug log shows this as the last TACACS response before throwing me a "401 Unauthorized"

10741001: Jul 26 09:44:56.474 EDT: TPLUS(00000000)/0/1A8BC9B0: Processing the reply packet
10741002: Jul 26 09:44:56.474 EDT: TPLUS: Processed AV priv-lvl=15
10741003: Jul 26 09:44:56.474 EDT: TPLUS: Processed AV timeout=60
10741004: Jul 26 09:44:56.474 EDT: TPLUS: Processed AV idletime=10
10741005: Jul 26 09:44:56.474 EDT: TPLUS: received authorization response for 0: PASS

SSH access with TACACS+ authentication against the same switches from the same client using the same credentials works as expected.

Michel Pedersen · ‎02-01-2013

I'm experiencing the same problems as you did. Did you ever get this resolved?

regards

Michel

Travis Hysuick · ‎02-01-2013

Hi there,

You may need to add the following command(s) for the authorization pieces:

ip http authentication aaa command-authorization

ip http authentication aaa exec-authorization

I use specific named method lists rather than relying on the default method list so that we can treat a console connection differently than a VTY session (gives you more granular control based on the access method - con, aux, ssh, and still allows for fallback to local credentials if the remote AAA server is unavailable)

aaa group server tacacs+ TAC_PLUS

server a.b.c.d

aaa authentication login default local

aaa authentication login TacLogin group TAC_PLUS local

aaa authorization console

aaa authorization config-commands

aaa authorization exec default local

aaa authorization exec TacAuth group TAC_PLUS local

aaa authorization commands 0 default local

aaa authorization commands 0 TacCommands0 group TAC_PLUS local

aaa authorization commands 1 default local

aaa authorization commands 1 TacCommands1 group TAC_PLUS local

aaa authorization commands 15 default local

aaa authorization commands 15 TacCommands15 group TAC_PLUS local

aaa accounting exec default start-stop group TAC_PLUS

aaa accounting commands 15 default start-stop group TAC_PLUS

Then down in the relevant http server and line input sections, we use this:

ip http authentication aaa login-authentication TacLogin

ip http authentication aaa command-authorization 0 TacCommands0

ip http authentication aaa command-authorization 1 TacCommands1

ip http authentication aaa command-authorization 15 TacCommands15

ip http authentication aaa exec-authorization TacAuth

!

line con 0

exec-timeout 15 0

logging synchronous

!

line aux 0

exec-timeout 15 0

logging synchronous

modem InOut

modem autoconfigure discovery

transport input all

flowcontrol hardware

!

line vty 0 4

exec-timeout 15 0

authorization commands 0 TacCommands0

authorization commands 1 TacCommands1

authorization commands 15 TacCommands15

authorization exec TacAuth

logging synchronous

login authentication TacLogin

transport input ssh

So OOB connection types (CON and AUX) use local credentials only, but TTY (SSH) and HTTP sessions use the TACACS server named method lists.

I hope this helps in your case, let me know if there's anything else I can provide.

gkuzmowycz · ‎02-04-2013

Thanks for taking the time to reply, although it's a bit odd to see a thread re-animated after 2.5 years.

After this post languished here for a while I opened a TAC case, which we worked in very great detail, until Cisco finally determined that we were dealing with a known bug, CSCeh06200. The solution was to upgrade the IOS on the switches. This last is more for the benefit of Michel Pedersen, who posted above.

Michel Pedersen · ‎02-05-2013

Thank you for your replies and the example configuration. I have adapted it to my current setup (using my existing AAA configuration). It's still not working on my 3750 switches with 12.2(58)SE2 but I'll try some variations of the configuration and do more debugging. If it doesn't work I'll contact our partner/TAC to see if it's the same bug that you mentioned (CSCeh06200) even though my software isn't listed there.

regards

Michel