Tacacs+ Authorization

Hi,
how to tell the Cisco Tacacs to only authorize users that have been authenticated by it and not by any other method? e.g. switchs are authenticating users locally and authorizing them against the tacacs server, how to prevent this?
Regards

Hi there Maik,
This can be accomplish using "named list", for example let's say that your VTY users will use the ACS for authentication and authorization but the users who access the Console port should use authentication only against local switch database with no authorization, so we do the following:
aaa new-model
tacacs-server X.X.X.X key cisco123
aaa authentication login myacs group tacacs+
aaa authentication login mylocal local
aaa authorization commands 15 mylocalautho group tacacs+
aaa authorization config-command
line console 0
login authentication mylocal
line vty 0 14
login authentication myacs
authorization command 15 mylocalautho
You can play with this and use different combinations for this feature depending on your requirements, let me know if you have any question about it.

Similar Messages

Cisco 300 support TACACS+ authorization and accounting

Hi All,
Can someone please confirm that does Cisco 300 switch supports tacacs authorization and accounting ? or just authentication ?
Kindly guide

Hello
Please review this - Cisco 300
res
Paul

SG300 tacacs authorization and accounting support

Hi All,
Can someone please confirm that does Cisco 300 switch supports tacacs authorization and accounting ? or just authentication ?
Kindly guide

Hello
Please review this - Cisco 300
res
Paul

TACACS+ authorization & pix6.3

I would like to use TACACS+ authorization for allowing some limited allowed commands for a particular group, on a TACACS+ authenticated user. When i allow the group enable, i can't seem to limit the command level.
aaa-server TACACS_SVR protocol tacacs+
aaa authentication ssh console TACACS_SVR LOCAL
aaa authentication enable TACACS_SVR
aaa authorization command TACACS_SVR
ssh x.x.x.x x.x.x.x outside
ssh timeout 5

aaa accounting command level helps enable accounting for all commands at the specified privilege level.Refer the URL
http://www.cisco.com/en/US/products/sw/secursw/ps4911/products_user_guide_chapter09186a00803deb15.html#wp1017641

TACACS Authorization of Web Interface on Aironet 1200 AP

I have the Aironet 1200 AP setup to authenticate and perform authorization for the CLI via TACACS. That is working fine.
However, the web interface is failing "ip http authentication". (Slight caveat - it works for a local user in the local AP DB - it does not work when it goes to CiscoSecure ACS to authenticate/authorize).
I can get to some pages (prompt and pass authentication), but certain pages (e.g. Services>>SNMP) where configuration steps are taken cause a second prompt is presented, username and password is provided, and it fails.
This is only evident from the output of a "debug ip http authentication"
What do I need to configure in ACS to make this work?
Relevant portion of config:
aaa authentication login default group tacacs+ local
aaa authentication enable default group tacacs+ enable
aaa authorization exec default group tacacs+ local
no ip http server
ip http authentication aaa
ip http secure-server
Sep 7 13:40:59.885: HTTP AAA picking up console Login-Authentication List name: default
Sep 7 13:40:59.885: HTTP AAA picking up console Exec-Authorization List name: default
Sep 7 13:40:59.909: HTTP: Authentication failed for level 15
Sep 7 13:41:06.757: HTTP AAA picking up console Login-Authentication List name: default
Sep 7 13:41:06.757: HTTP AAA picking up console Exec-Authorization List name: default
Sep 7 13:41:06.780: HTTP: Authentication failed for level 15
This document appears to describe a scenario similar to mine, but is for http - not HTTPS:
Local Authentication for HTTP Server Users
http://www.cisco.com/en/US/customer/tech/tk59/technologies_configuration_example09186a0080178a51.shtml#tac-win
Any ideas what I may be missing here?
Thanks,
Jeff

I found the answer was to use a more specific "ip http authentication" statement. Specifically,it required the following:
CiscoSecure ACS:
Group Settings
Shell (exec)
Priv Level = 15
On the AP:
had to enable:
ip http authentication aaa login-authentication AP_Web (Named Method List)

Cisco Prime Infrastructure 1.3 Tacacs+ authorization problem

Hello,
We are having trouble setting our new installation of Cisco PI 1.3 to work with Tacacs+ configured on ACS 4.2.
We have followed procedure explained in Cisco PI 1.3 configuration guide and in Tacacs+ logs we can see that we have successful authentification but authorization is unsuccessful:
21/05/2013,16:36:44,Authen OK,pradoicic,admins,192.168.187.109,,192.168.187.109,wifi-prime-p-vm01,AP,ACS1AERO,1,,,192.168.187.109,No Filters activated.,,,No,
21/05/2013,16:36:44,Author failed,pradoicic,admins,192.168.187.109,,Service denied,protocol=HTTP service=NCS,NCS HTTP,192.168.187.109,wifi-prime-p-vm01,AP
We have added user group into ACS as is explained in configuration gude and we have also tried to add virtual domain at the beggining or at the and of the list but that didn't solve our problem.
Is there anything that we can do in order to make Cisco PI to authentificate users using Tacacs+?
Any help in finding solution for this problem will be very appreciated.
Regards,
Jelena

Hi,
On the Cisco PI side we have:
1. Added Tacacs+ server under Administration > AAA > TACACS+
We have entered all required parameters
2. Enabled AAA Tacacs+ mode under Administration > AAA > AAA Mode and we have choosed on auth failure or no server response oprion.
On the ACS side:
1. Under Network Configuration > New Entry we have added Cisco PI
2. Under Interface Configuration >TACACS+ (Cisco IOS) > New Services >
we have added Prime and HTTP (we have checked box infront of these service).
3. Under Group Setup > Edit Settings > prime HTTP service we have added custom attributes that we have copied from Cisco PI Admin group. We have also exported virtual domain information from Prime and have imported them on the beggining of the custom attributes and we have also tried to place that virtual domain information on the end but we have the same behavior.
For some reason ACS doesn't know how to return authorization information.
Regards,
Jelena

TACACS+ Authorization on 300 Series Switches

I was wondering if anyone could give me instructions on how to set up ACS for TACACS+ on a 300 series switch using Authorization? I can get it to work to authenticate, but the authorization doesn't seem to work like a catalyst switch. Thanks in advance for any help!

Brandon, thanks for the link, but this is for the older software before they included authorization (the v1.4). I've looked through a bunch of manuals and tried to find examples online, but it doesn't seem like anyone has anything out there I can find.

Tacacs authorization and Priv levels

Hi
I'm strugling with TACACS+ and priv levels, and hoping someone out there can help me solve an issue.
So, in this enviroment we need the following:
Read-only users
Users with access to some configuration commands.
Okay, the TACACS configuration for the read-only users looks like this:
group = readonly-users {
   default service = deny
   cmd = show
      permit running-config
      permit interface
      permit privilege
      permit vlan
      deny .*
   service = exec
      priv-lvl = 15
# Note that priv lvl 15 has been set to allow the users to run the "show running-config", all other commands than the one mentioned is denied.
The TACACS configuration for the Users with configuration access looks like this.
group = restricted-user {
   default service = deny
   cmd = show
      permit interface
      permit vlan
      permit privilege
      deny .*
   service = exec
      priv-lvl = 7
And the following has been configured on the switches to allow further configurations, these commands we had to enable after I had made the previous read-only user in tacacs:
privilege interface level 7 switchport access vlan
privilege interface level 7 switchport mode access
privilege interface level 7 switchport voice vlan
privilege configure level 7 interface
privilege exec level 7 configure terminal
privilege exec level 7 show running-config
privilege exec level 7 write memory
It all worked just fine, the read-only users only had access to the commands configured in TACACS. But when I configured the users with configuration access and enter the privilege commands on the switch it stopped working.
Somehow the privilege commands on the switch applies to all privilege levels above lvl 7. Meaning that my read-only users with priv lvl 15, all commands exept show commands denied, they can suddenly enter priviledged exec mode because I allowed the priv lvl 7 users to enter it.
This does not make sense to me, because I've read on cisco's HP that when configuring privilege level commands on the equipment, you allow only that level to access the command, and not all above.
I hope someone can help me with this issue, and it should be solved in the TACACS configuration, because the TACACS server is controlling over 500 switches and routers. So it aint just a question of reconfiguring the switches, that would take the rest of 2011.
I hope you guys know the answer to this.
Thanks in advance.
Kind regards

Thanks for your answer.
Well when I started to configure this TACACS setup, I tried to create 2 profiles with privilege level 15 and just allow/deny the different commands. But the thing is that you cannot allow all commands in the TACACS configuration. For example, you cannot give a user privilege level 15 and deny all commands, but allow the user to configure VLANs on interfaces, and duplex settings which is what I want the users to be able to do.
That's why I needed to configure the commands to be accessable from privilege level 7 on the equipment.
If only I could create a profile with privilege level 15 and give the user access to the commands he needs, and only those from the TACACS configuration file, that would make it allot easier, but that just aint the way TACACS works, unfortunately.

ACS 5.3 Showing Clear Text Password in Authorization reports

Hello,
When a tacacs user is changing the local password on the router (for local user), the acs 5.3 is showing the new password in clear text in authorization reports/logs.
This behaviour is seen on acs 5.x, whereas acs 4.2 is showing encrypted password in the reports.
I have checked debugs on Router and it is sending password in clear text in Tacacs Authorization packet but encrypted password in Tacacs Accounting logs.
Debug tacacs accounting
debug aaa accounting
4w3d: TPLUS: Received accounting response with status PASS
4w3d: TPLUS: Queuing AAA Accounting request 208 for processing
4w3d: TPLUS: processing accounting request id 208
4w3d: TPLUS: Sending AV task_id=459
4w3d: TPLUS: Sending AV timezone=UTC
4w3d: TPLUS: Sending AV service=shell
4w3d: TPLUS: Sending AV priv-lvl=15
4w3d: TPLUS: Sending AV cmd=username sansehga privilege 15 password *****
4w3d: TPLUS: Accounting request created for 208(sanjay)
debug tacas authorization
debug aaa authorization
4w3d: AAA/MEMORY: create_user (0x851611DC) user='sanjay' ruser='R1' ds0=0
port='tty7' rem_addr='10.76.212.159' authen_type=ASCII service=NONE priv=15
initial_task_id='0', vrf= (id=0)
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): Port='tty7' list='' service=CMD
4w3d: AAA/AUTHOR/CMD: tty7(1390711548) user='sanjay'
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): send AV service=shell
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): send AV cmd=username
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): send AV cmd-arg=sansehga
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): send AV cmd-arg=privilege
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): send AV cmd-arg=15
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): send AV cmd-arg=password
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): send AV cmd-arg=sehgal
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): send AV cmd-arg=<cr>
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): found list "default"
4w3d: tty7 AAA/AUTHOR/CMD(1390711548): Method=tacacs+ (tacacs+)
4w3d: AAA/AUTHOR/TAC+: (1390711548): user=sanjay
4w3d: AAA/AUTHOR/TAC+: (1390711548): send AV service=shell
4w3d: AAA/AUTHOR/TAC+: (1390711548): send AV cmd=username
4w3d: AAA/AUTHOR/TAC+: (1390711548): send AV cmd-arg=sansehga
4w3d: AAA/AUTHOR/TAC+: (1390711548): send AV cmd-arg=privilege
4w3d: AAA/AUTHOR/TAC+: (1390711548): send AV cmd-arg=15
4w3d: AAA/AUTHOR/TAC+: (1390711548): send AV cmd-arg=password
4w3d: AAA/AUTHOR/TAC+: (1390711548): send AV cmd-arg=sehgal
4w3d: AAA/AUTHOR/TAC+: (1390711548): send AV cmd-arg=<cr>
4w3d: AAA/AUTHOR (1390711548): Post authorization status = PASS_ADD
Please share if someone has found the fix to this problem.
Regards,
Akhtar

Thanks Tarik,
But it seems it did not help overall
Akhtar: Cisco needs long time to fix bugs unless it is P1 or P2 bug. Otherwise they'll do it at their leisure.
If you are not on latest patch already then upgrade. If you are already on the latest patch then wait for the next one. If your bug is not mentioned to be fixed on the resolved caveats don't panic. I've seen many bugs fixed but not mentioned in the release notes. What you need to do is to contact TAC so they contact the BU for your behalf to confirm if the bug is resolved or not.
Regards,
Amjad

How to configure ACS 5.2 for policy condition on TACACS+ Service

In https://supportforums.cisco.com/message/3953175#3953175 thread, I was able to get the ACS 5.2 work with SRX for both SSH CLI and J-Web TACACS+ accounts. However, I found the behavior is different on our production environment. I found our ACS 5.2 was configured authorization rule with condition "TACACS+ Service" = "junos-exec". I don't know how to configure this on my ACS 5.2 Please guide me how to configure this.
I found there was NO TACACS+ "Authorization Request" when access via J-Web in our production SRX and ACS. However, there were TACACS+ "Authorzation Request" when access via J-Web in our production SRX and ACS. The difference between my lab ACS and production ACS is the authorization rule condition. In my condition, I configure with all "SRX" Device Type. but in our production ACS 5.2, it was configure to TACACS+ Service=junos-exec. so I like to test it in our lab to find out the difference. Thanks.

I would suggest you to go through the below two link.
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.2/migration/guide/Migration_Configure.html
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.2/user/guide/common_scenarios.html

Cisco ISE with TACACS+ and RADIUS both?

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

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).

Tacacs user authentication not working

I am trying to setup my AP to use tacacs+ running on Cisco ACS to authenticate users logging into the AP with no success.
Here is the AP config. At the end of the config you can see the debugs that are running and the output of those when I try to login to the unit with the web browser.
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
hostname ap1250
aaa new-model
aaa group server radius rad_eap
aaa group server radius rad_mac
aaa group server radius rad_acct
aaa group server radius rad_admin
cache expiry 1
cache authorization profile admin_cache
cache authentication profile admin_cache
aaa group server tacacs+ tac_admin
server 192.168.1.25
cache expiry 1
cache authorization profile admin_cache
cache authentication profile admin_cache
aaa group server radius rad_pmip
aaa group server radius dummy
aaa authentication login default local cache tac_admin group tac_admin
aaa authentication login eap_methods group rad_eap
aaa authentication login mac_methods local
aaa authorization exec default local cache tac_admin group tac_admin
aaa accounting network acct_methods start-stop group rad_acct
aaa cache profile admin_cache
all
aaa session-id common
power inline negotiation prestandard source
username seth privilege 15 password 7 02050D480809
username Cisco privilege 15 password 7 072C285F4D06
bridge irb
interface Dot11Radio0
no ip address
no ip route-cache
shutdown
station-role root
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
bridge-group 1 spanning-disabled
interface Dot11Radio1
no ip address
no ip route-cache
shutdown
dfs band 3 block
channel dfs
station-role root
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
bridge-group 1 spanning-disabled
interface GigabitEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
bridge-group 1
no bridge-group 1 source-learning
bridge-group 1 spanning-disabled
interface BVI1
ip address 192.168.1.60 255.255.255.0
no ip route-cache
ip http server
ip http authentication aaa
no ip http secure-server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
ip radius source-interface BVI1
tacacs-server host 192.168.1.25 port 49 key 7 00071A150754
radius-server attribute 32 include-in-access-req format %h
radius-server vsa send accounting
bridge 1 route ip
line con 0
line vty 0 4
end
ap1250# sho debug
General OS:
TACACS+ authentication debugging is on
TACACS+ authorization debugging is on
AAA Authentication debugging is on
ap1250#
*Mar 1 00:25:56.239: AAA/BIND(00000024): Bind i/f
*Mar 1 00:25:56.243: AAA/AUTHEN/LOGIN (00000024): Pick method list 'default'

The radio's are shut down as I do not have an SSID configured on the unit either at this time. I was merely trying to get the setup for login authentication.
I did also have a local user name and password defined but was unable to use that login either.
I tried the config on another AP and got it to work by changing the statement to read
aaa authentication login default local group tac_admin
This was done by not checking the box for caching.
Seth

WLC - ACS TACACS+ mismatch shared secred

Hello,
I confgured TACACS+ Authentication on WLC 5.0.235.3 for management login.
On ACS 5.1.0.44 I get the message
"13011 invalid tacacs+ request packet - possibly mismatched shared secrets"
after login.
I compared the shared secrets (blanks) or created new secrets, the message still appears.
Some ideas?
Regard Sven

Hello David,
WLC Version is 7.0.235.3, sorry.
Authentication on WLC and ACS use TACACS not Radius.
On ACS:
Authentication Result
Type=Drop
Authen-Reply-Status=Error
Steps
Received TACACS Authentication START Request
Invalid TACACS request packet - possibly mismatched shared secrets
Output from WLC:
(Cisco Controller) >debug aaa tacacs enable
(Cisco Controller) >*tplusTransportThread: Feb 06 11:37:46.720: Exhausted all available servers for Auth/Author packet
*tplusTransportThread: Feb 06 11:53:34.728: Forwarding request to 10.54.159.11 port=49
*tplusTransportThread: Feb 06 11:53:34.732: AUTH Socket closed underneath
*tplusTransportThread: Feb 06 11:53:39.948: No auth response from: 10.54.159.11, retrying with next server
*tplusTransportThread: Feb 06 11:53:39.948: Preparing message for retransmit. Decrypting first
*tplusTransportThread: Feb 06 11:53:39.948: Forwarding request to 10.54.159.12 port=49
*tplusTransportThread: Feb 06 11:53:39.951: AUTH Socket closed underneath
*tplusTransportThread: Feb 06 11:53:45.164: No auth response from: 10.54.159.12, retrying with next server
*tplusTransportThread: Feb 06 11:53:45.164: Preparing message for retransmit. Decrypting first
*tplusTransportThread: Feb 06 11:53:45.164: Forwarding request to 10.54.159.11 port=49
*tplusTransportThread: Feb 06 11:53:45.166: AUTH Socket closed underneath
*tplusTransportThread: Feb 06 11:53:50.380: Exhausted all available servers for Auth/Author packet
(Cisco Controller) >*tplusTransportThread: Feb 06 11:55:55.564: Forwarding request to 10.54.159.11 port=49
*tplusTransportThread: Feb 06 11:55:55.566: AUTH Socket closed underneath
*tplusTransportThread: Feb 06 11:56:00.780: No auth response from: 10.54.159.11, retrying with next server
*tplusTransportThread: Feb 06 11:56:00.780: Preparing message for retransmit. Decrypting first
*tplusTransportThread: Feb 06 11:56:00.780: Forwarding request to 10.54.159.12 port=49
*tplusTransportThread: Feb 06 11:56:00.783: AUTH Socket closed underneath
*tplusTransportThread: Feb 06 11:56:05.996: No auth response from: 10.54.159.12, retrying with next server
*tplusTransportThread: Feb 06 11:56:05.996: Preparing message for retransmit. Decrypting first
*tplusTransportThread: Feb 06 11:56:05.996: Forwarding request to 10.54.159.11 port=49
*tplusTransportThread: Feb 06 11:56:05.998: AUTH Socket closed underneath
(Cisco Controller) >show tacacs ?
acct           TACACS+ accounting server.
athr           TACACS+ authorization server.
auth           TACACS+ authentication server.
summary        Displays TACACS+ summary.
(Cisco Controller) >show tacacs summary
Authentication Servers
Idx Server Address    Port    State     Tout
1    10.54.159.11      49      Enabled   5
2    10.54.159.12      49      Enabled   5
Authorization Servers
Idx Server Address    Port    State     Tout
Accounting Servers
Idx Server Address    Port    State     Tout
(Cisco Controller) >show tacacs auth ?
statistics     Displays TACACS+ authentication server statistics.
(Cisco Controller) >show tacacs auth stat
Authentication Servers:
Server Index..................................... 1
Server Address................................... 10.54.159.11
Msg Round Trip Time.............................. 0 (msec)
First Requests................................... 24
Retry Requests................................... 0
Accept Responses................................. 0
Reject Responses................................. 0
Error Responses.................................. 0
Restart Responses................................ 0
Follow Responses................................. 0
GetData Responses................................ 0
Encrypt no secret Responses...................... 0
Challenge Responses.............................. 0
Malformed Msgs................................... 0
Bad Authenticator Msgs........................... 0
Timeout Requests................................. 24
Unknowntype Msgs................................. 0
Other Drops...................................... 0
Server Index..................................... 2
--More-- or (q)uit
Server Address................................... 10.54.159.12
Msg Round Trip Time.............................. 0 (msec)
First Requests................................... 0
Retry Requests................................... 0
Accept Responses................................. 0
Reject Responses................................. 0
Error Responses.................................. 0
Restart Responses................................ 0
Follow Responses................................. 0
GetData Responses................................ 0
Encrypt no secret Responses...................... 0
Challenge Responses.............................. 0
Malformed Msgs................................... 0
Bad Authenticator Msgs........................... 0
Timeout Requests................................. 24
Unknowntype Msgs................................. 0
Other Drops...................................... 0

WLC s/w v4.1 and TACACS unreachable

In,
Cisco WLC_Config Guide_Web & CLI_Release 4.1
it says,
"If the TACACS+ authorization server becomes unreachable or unable to authorize, users are unable to log into the controller."
Does this mean it does not support a fail-safe password like IOS does where the Enable password can be used to get into a router if TACACS+ is unreachable?

Hi Mark,
No, the local database is always queried first.
Please read Chapter 5 and the section on configuring TACACS:
"You can specify the order of authentication when multiple databases are configured, click Security > Priority Order > Management User. The Priority Order > Management User page will appear."
It goes on further to explain:
For Authentication Priority, choose either Radius or TACACS+ to specify which server has priority over the other when the controller attempts to authenticate management users. By default, the local database is always queried first. If the username is not found, the controller switches to the TACACS+ server if configured for TACACS+ or to the RADIUS server if configured for Radius. The default setting is local and then Radius."
Hope this helps.
Paul

Cannot login to 4400 using ACS-TACACS+

Hello,
I am using a 4402 running 4.2.207 setup with TACACS+ to management user authentication. I am running ACS 4.2 in a VM. I went thru the setup and added the ciscowlc-common attribute under the user group and added role1=ALL.
I cannot get any user to login to the WLC. If I turn off the ACS service the local auth works fine. The ACS says that the authentication passed in the log but all I get when I try to connect to the WLC is prompted over and over again for username and password.
Here are some captures from the WLC when I try to login to it from the web browser.
Mon Aug 9 15:43:06 2010: Forwarding request to 192.168.1.90 port=49
Mon Aug 9 15:43:06 2010: tplus response: type=1 seq_no=2 session_id=223f532e length=16 encrypted=0
Mon Aug 9 15:43:06 2010: TPLUS_AUTHEN_STATUS_GETPASS
Mon Aug 9 15:43:06 2010: auth_cont get_pass reply: pkt_length=22
Mon Aug 9 15:43:06 2010: processTplusAuthResponse: Continue auth transaction
Mon Aug 9 15:43:06 2010: tplus response: type=1 seq_no=4 session_id=223f532e length=6 encrypted=0
Mon Aug 9 15:43:06 2010: tplus_make_author_request: athr server not found
Mon Aug 9 15:43:06 2010: tplus_make_author_request() from tplus_authen_passed returns rc=1
(Wireless) >show tacacs auth statistics
Authentication Servers:
Server Index..................................... 1
Server Address................................... 192.168.1.90
Msg Round Trip Time.............................. 0 (1/100 second)
First Requests................................... 1
Retry Requests................................... 1
Accept Responses................................. 1
Reject Responses................................. 0
Error Responses.................................. 0
Restart Responses................................ 0
Follow Responses................................. 0
GetData Responses................................ 0
Encrypt no secret Responses...................... 0
Challenge Responses.............................. 0
Malformed Msgs................................... 0
Bad Authenticator Msgs........................... 0
Timeout Requests................................. 0
Unknowntype Msgs................................. 0
Other Drops...................................... 0
show aaa auth
Management authentication server order:
1............................................ tacacs
2............................................ local
Any help is greatly appreciated.
Seth

Did you also configure the server info under TACACS Authorization and Accounting on the controller? You can get this debug response if you only set up the server under the Authentication section.

Tacacs+ Authorization

Similar Messages

Maybe you are looking for