×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

TACACS+ authorisation of WLC 4402 against ACS 4.2

Answered Question
Apr 6th, 2012
User Badges:

I'm having some trouble to get TACACS+ authorisation working on my WLAN controller against Cisco Secure ACS.


The WLAN controller is mode AIR-WLC4402-25-K9 running OS version 7.0.230.0

The Cisco ACS server is running ACS version 4.2


The controller is configured for TACACS+ authentication and authorisation (and accounting) against a pair of ACS servers

When I try to log on to the WLAN controller (using either the webinterface or an ssh connection), the ACS produces an entry in the Passed Authentications log.

Therefore I conclude that the authentication part is working as designed.


The WLAN controller produces the following message entry:

Login failed for the user:<username>. Service-Type is not present or it doesn't allow READ/WRITE permission..


When enabling debugging using debug aaa tacacs enable, the following log entries show up on a failed authorisation attempt:

*tplusTransportThread: Apr 06 12:39:51.798: Forwarding request to x.x.x.x port=49

*tplusTransportThread: Apr 06 12:39:51.800: tplus auth response: type=1 seq_no=2 session_id=cbd3b081 length=16 encrypted=0

*tplusTransportThread: Apr 06 12:39:51.800: TPLUS_AUTHEN_STATUS_GETPASS

*tplusTransportThread: Apr 06 12:39:51.800: auth_cont get_pass reply: pkt_length=26

*tplusTransportThread: Apr 06 12:39:51.800: processTplusAuthResponse: Continue auth transaction
*tplusTransportThread: Apr 06 12:39:51.810: tplus auth response: type=1 seq_no=4 session_id=cbd3b081 length=6 encrypted=0

*tplusTransportThread: Apr 06 12:39:51.810: tplus_make_author_request() from tplus_authen_passed returns rc=0

*tplusTransportThread: Apr 06 12:39:51.810: Forwarding request to x.x.x.x port=49

*tplusTransportThread: Apr 06 12:39:51.812: author response body: status=39 arg_cnt=208 msg_len=13224 data_len=54796

*tplusTransportThread: Apr 06 12:39:51.812: Tplus authorization for <username> failed status=39

A second failed attempt produces:

*tplusTransportThread: Apr 06 12:41:07.270: Forwarding request to x.x.x.x port=49

*tplusTransportThread: Apr 06 12:41:07.272: tplus auth response: type=1 seq_no=2 session_id=7d6f690e length=16 encrypted=0

*tplusTransportThread: Apr 06 12:41:07.272: TPLUS_AUTHEN_STATUS_GETPASS

*tplusTransportThread: Apr 06 12:41:07.272: auth_cont get_pass reply: pkt_length=26

*tplusTransportThread: Apr 06 12:41:07.272: processTplusAuthResponse: Continue auth transaction
*tplusTransportThread: Apr 06 12:41:07.282: tplus auth response: type=1 seq_no=4 session_id=7d6f690e length=6 encrypted=0

*tplusTransportThread: Apr 06 12:41:07.282: tplus_make_author_request() from tplus_authen_passed returns rc=0

*tplusTransportThread: Apr 06 12:41:07.283: Forwarding request to x.x.x.x port=49

*tplusTransportThread: Apr 06 12:41:07.284: author response body: status=67 arg_cnt=88 msg_len=9085 data_len=60035

*tplusTransportThread: Apr 06 12:41:07.284: Tplus authorization for <username> failed status=67

Subsequent attempts produce a different status, arg_cnt, msg_len and data_len value each time

I have a 5508 controller running the same software version (7.0.230.0) and authenticating against the same Cisco Secure ACS server with the same credentials. When I (succesfully) log on there, the debug aaa tacacs output is as follows:


*tplusTransportThread: Apr 06 12:45:36.269: Forwarding request to x.x.x.x port=49

*tplusTransportThread: Apr 06 12:45:36.328: tplus auth response: type=1 seq_no=2 session_id=d2344c9a length=16 encrypted=0

*tplusTransportThread: Apr 06 12:45:36.328: TPLUS_AUTHEN_STATUS_GETPASS

*tplusTransportThread: Apr 06 12:45:36.328: auth_cont get_pass reply: pkt_length=26

*tplusTransportThread: Apr 06 12:45:36.328: processTplusAuthResponse: Continue auth transaction

*tplusTransportThread: Apr 06 12:45:36.418: tplus auth response: type=1 seq_no=4 session_id=d2344c9a length=6 encrypted=0

*tplusTransportThread: Apr 06 12:45:36.418: tplus_make_author_request() from tplus_authen_passed returns rc=0

*tplusTransportThread: Apr 06 12:45:36.418: Forwarding request to x.x.x.x port=49

*tplusTransportThread: Apr 06 12:45:36.477: author response body: status=1 arg_cnt=6 msg_len=0 data_len=0

*tplusTransportThread: Apr 06 12:45:36.477: arg[0] = [16][role1=MANAGEMENT]

*tplusTransportThread: Apr 06 12:45:36.477: arg[1] = [14][role2=WIRELESS]

*tplusTransportThread: Apr 06 12:45:36.477: arg[2] = [10][role3=WLAN]

*tplusTransportThread: Apr 06 12:45:36.477: arg[3] = [16][role4=CONTROLLER]

*tplusTransportThread: Apr 06 12:45:36.477: arg[4] = [14][role5=SECURITY]

*tplusTransportThread: Apr 06 12:45:36.477: arg[5] = [14][role6=COMMANDS]

*tplusTransportThread: Apr 06 12:45:36.477:

User has the following mgmtRole 1f8

Notice the difference in the author response body status and arg_cnt. on 12:45:36:477. The 5508 comes back with a status 1 and 6 argument, where the 4402 comes back with a very erratic/illogic status and argument count. Is this a bug in the 4402 7.0.230.0 release or in the Cisco ACS version?

Correct Answer by Stephen Rodriguez about 5 years 4 months ago

And make sure you have all three servers defined


Steve


Sent from Cisco Technical Support iPhone App

Correct Answer by Scott Fella about 5 years 4 months ago

Have you tried to recreate the tacacs entry on the 4400? I would try that first just in case the shared secret was fat fingered on one of the AAA settings.


Thanks,


Scott Fella


Sent from my iPhone

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
ict.infra.inter... Fri, 04/06/2012 - 04:15
User Badges:

Yes, the ACS server is configured correctly to authorise users from a WLC, that is why the 5508 WLC is working as designed (the log entries from the 5508 match the ones described in your link).


I highly suspect some sort of issue between the 4402 and the ACS server, since the fail status value from the ACS is different each time, the arg_cnt doesn't make any sense and the msg_len and data_len are very large

Correct Answer
Scott Fella Fri, 04/06/2012 - 04:33
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    The Hall of Fame designation is a lifetime achievement award based on significant overall achievements in the community. 

  • Cisco Designated VIP,

    2017 Wireless

Have you tried to recreate the tacacs entry on the 4400? I would try that first just in case the shared secret was fat fingered on one of the AAA settings.


Thanks,


Scott Fella


Sent from my iPhone

ict.infra.inter... Fri, 04/06/2012 - 05:08
User Badges:

Since the WCS is part of a larger group of devices that do authenticate and authorise properly, the entry on the ACS side must have been right.


Your post did prompt me however to re-enter the tacacs+ authorisation server details in the WLC again and for some unfathomable reason, after I did that, everything worked. How I was able to mess up entering the shared secret and mess up entering the confirmation of the shared secret in exactly the same way is beyond me.


Most likely they were correct in the authentication part, hence the passed authentication in the ACS.


Thank you very much for thinking along!

Correct Answer
Stephen Rodriguez Fri, 04/06/2012 - 05:05
User Badges:
  • Purple, 4500 points or more

And make sure you have all three servers defined


Steve


Sent from Cisco Technical Support iPhone App

Actions

This Discussion

Related Content

 

 

Trending Topics - Security & Network