Configuring WLC 4402 TACACS+ authentication using Cisco ACS 5.0

Unanswered Question
Aug 23rd, 2009
User Badges:

Hello,

We added AAA client in the Cisco ACS 5.0 for WLC 4402 (TACACS+ Authentication) and configured WLC 4402 to use TACACS+ authentication for the management access.

We can't get this work for some reasons.


Other Cisco routers and switches all worked fine with TACACS+ authentication.


This is a TACACS debug output from the WLC;


Sun Aug 23 16:19:06 2009: tplus response: type=1 seq_no=2 session_id=f59bbf0b length=15 encrypted=0

Sun Aug 23 16:19:06 2009: TPLUS_AUTHEN_STATUS_GETPASS

Sun Aug 23 16:19:06 2009: auth_cont get_pass reply: pkt_length=28

Sun Aug 23 16:19:06 2009: processTplusAuthResponse: Continue auth transaction

Sun Aug 23 16:19:06 2009: tplus response: type=1 seq_no=4 session_id=f59bbf0b length=6 encrypted=0

Sun Aug 23 16:19:06 2009: tplus_make_author_request() from tplus_authen_passed returns rc=0

Sun Aug 23 16:19:06 2009: Forwarding request to 192.168.0.5 port=49

Sun Aug 23 16:19:11 2009: sendTplusMessage: connect timeout: 115:Operation now in progress

Sun Aug 23 16:19:16 2009: Exhausted all available servers


Please review and let me know if I missed anything. Thanks.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Cory Peterson Thu, 10/21/2010 - 07:13
User Badges:

Where do you add the custom attributes in ACS 5.X? I can not find where to apply these settings.

Cory Peterson Thu, 10/21/2010 - 10:27
User Badges:

I tried your guide and it hits the rules when I try to authenticate. I also see authentication pass but never get access to the webgui, or the CLI.


The following is the error I get when trying to login.


*Oct 21 12:17:47.069: %EMWEB-1-LOGIN_FAILED: ews_auth.c:2104 Login failed. User:testuser. Service-Type is not present or it doesn't allow READ/WRITE permission..

Erick Delgado Thu, 10/21/2010 - 11:06
User Badges:
  • Bronze, 100 points or more

I am sorry I forget to change something. under the shell profile it is Role1=ALL. Please change that to role1=ALL. The WLC is very case sensitive.


Hope this helps.


You can call me directly if you have any more issues.

jimlopresto Thu, 10/28/2010 - 10:03
User Badges:

First, thanks for your screen shots, they helped very much.


Particulars:


ACS 5.2.0.26

WLC 4400 - 6.0.196.0

RADIUS server running on an RSA SecurID appliance.


We are in the process of upgrading our ACS infrastructure to 5.x.  We are using the appliances and are testing in our lab.  Following the provided screen shots, I am able to successfully log in to the WLC as an administrator via the web interface or SSH.


However, as soon as I change the authentication to use the RADIUS server, I am unable to log in to the WLC.  Looking at the aaa debug on the WLC, it is clear that the ACS is not sending the role1=ALL statement to the WLC.  However, as far as the ACS is concerned, I successfully authenticated against the RADIUS server.


Has anybody gotten this to work when using an external identity store, particularly RADIUS.  I am hoping I just need to tweak an attribute setting somewhere.


Thanks.


Jim

Cory Peterson Thu, 10/28/2010 - 11:02
User Badges:

Jim,


I am having the same Issue. I will be working with TAC on this and will update as I find anything out.


Cory

aneelaka Thu, 10/28/2010 - 11:28
User Badges:

For authorization attributes only TACACS supports it, you cannot use Radius

jimlopresto Thu, 10/28/2010 - 12:50
User Badges:

Hi:


I was not clear in my post.


I am using TACACS+ between the WLC and the ACS.  The only RADIUS communication is between the ACS and the RADIUS server on the RSA SecurID appliance.


What I was trying to get across was that perhaps there is an attribute the RADIUS server needs to pass to the ACS in order for this to work.


Jim

jimlopresto Thu, 10/28/2010 - 12:46
User Badges:

Cory:


Looking forward to hearing what TAC has to say.  We cannot be the only ones having this issue with external identity store authentication.


Good luck.


Jim

Cory Peterson Fri, 10/29/2010 - 05:22
User Badges:

Jim,


We have found the fix just one little check box as you will...


You need to make sure you have an authentication server and an authorization server. I did not have an authorization server entered in the ALC.


You can just point to the ACS for both Authentication and Authorization.




-Cory

jimlopresto Fri, 10/29/2010 - 07:22
User Badges:

Cory:


Glad you found the fix.  Unfortunately this setting was already enabled on our WLC, it had to be in order to get this to work under ACS 4.x.  So, whatever issue we are experiencing is different from yours.


I will continue to investigate.  Congratulations again in getting over this hurdle.


Jim

Cory Peterson Fri, 10/29/2010 - 07:26
User Badges:

Jim,


Also be sure the Shell Commands are exactly as follows. They are Case sensitive.


-Cory

jimlopresto Fri, 10/29/2010 - 08:37
User Badges:

Cory:  All my settings are good. I can successfully authenticate when using the local identity store. It's when the access policy uses the external Radius server that it fails.   Debugs on the WLC show the role1=ALL line not being passed when using external authentication.    Jim

Cory Peterson Fri, 10/29/2010 - 08:44
User Badges:

Jim,


Is your hit count increasing on your authorization Rules?


And you have a rule like below?



Just trying to see if our configs line up. Seeing we are both using 5.2 - The settings should be the same. At least that is what I would think....


-Cory

jimlopresto Fri, 10/29/2010 - 13:48
User Badges:

Hey Cory:


My configuration is slightly different than yours.  Just to keep things simple, I setup our lab ACS to mimick what Erick Delgado provided in his screen captures.  As I pointed out in the beginning, when I use a local account on the ACS I have no problem authenticating and logging into the WLC web interface.  I have not been able to accomplish this when I configure RADIUS as the external identity store for authentication.  We want One Time Passwords when we log in to our network infrastructure devices, so we do not leverage AD or LDAP for this reason.


To answer your question, yes, I am seeing hits on the rules and the ACS logs are showing successful authentication.  I notice from your screen shots that under the Access Policies, you have an AD-1 policy.  I am going to assume that your external authentication store is AD.  Our external identity store is ultimately SecurID, with communication between the ACS and SecurID server being RADIUS.


When using RADIUS as the external identity store, there is not as much flexibility in working with groups as there is with AD and LDAP.  In ACS 4.x, we can group user accounts on the ACS into specific groups but configure the individual user accounts to use RADIUS for authentication.  This particular issue we have been discussing, logging in to the WLC web interface, works fine in that environment.  However, with ACS 5.x, local user accounts can only be authenticated locally.  You cannot tell the ACS to look at an external authentication source to authenticate local user accounts.  Thus, it makes group management difficult because we cannot have any user accounts locally on the ACS and leverage RADIUS to authenticate those local users.


Anyway, thanks for your feedback and this is probably going to require a TAC case just so I can get a better idea of what we can and cannot do in ACS 5.x.


Good luck going forward.


Jim

Erick Delgado Fri, 10/29/2010 - 13:52
User Badges:
  • Bronze, 100 points or more

Hello Jim,


looks like the issue is with external DB and not related to attributes configuration for WLC.


Please contact me on Monday and I will take a look to your ACS.

jimlopresto Wed, 11/03/2010 - 13:29
User Badges:

Hi Erick:


I was able to get the user-group mapping working leveraging the cisco-av-pair attribute from the RADIUS server.  However, in both the case of gaining Administration access to the WLC as well as trying to apply Shell Profiles and Command Sets to a switch, when using the RADIUS server as the Identity Store, I cannot get things to work.  If I change the Identity Store to local and use a local user account, both Administrative access to the WLC and the Shell Profiles/Command Sets regarding the switch work.


Is there something that needs to be tweaked on the ACS when using RADIUS as an Identity Store, or does the ACS not support the RADIUS attributes in these particular situations?  Given that ACS 4.2 supports Administrative access to the WLC when leveraging RADIUS as the external Identity Store, I would think it should work.


Any thoughts, ideas?


Thanks.


Jim

jimlopresto Thu, 11/04/2010 - 18:19
User Badges:

Well, I found the answer to my own questions after a lot of trial and error and digging.  I still may open a TAC case just to make sure what I found is the only way/best practice.  In case anybody has a similar setup, here is how I was able to get authentication and authorization using a One Time Password working under ACS 5.2.


The answer lay in the ACS 5.1 migration guide under in the following location:


http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/migration/guide/Migration_Configure.html#wp1053387


This is a 50,000 foot view and I am not going into explicit detail as I am assuming the reader is familiar with the basic workings of the different sections of the ACS.


  1. First, create an Identity Store Sequence which contains your OTP server, in my case the RADIUS server running on the SecurID appliance and the local identity store.

  2. Create a local user account on the ACS that matches the account you are authenticating against on the RADIUS server and add it to a local Identity Group on the ACS.

  3. In the Access Policies section, you can create a new Access Policy and under Identity, select the Identity Store Sequence "container" you created in step #1 above.  If you create a new Access Policy, you will need to make sure that you create a rule in the Service Selection Rules section that matches your requirements and sends the traffic to your new Access Policy.  Otherwise, you can change the Identity configuration on the Default Device Admin Access Policy.

  4. In the Authorization section, create a rule in which one of the conditions is the local identity group that the local user, belongs.  The result of this rule is to apply the Shell Profile you created in order to log in to the WLC as an administrator.

  5. Connect to the WLC web interface and attempt to log in with your OTP credentials.  You will then be authenticated and authorized and able to successfully administer the WLC.


It appears to me that in order to apply Shell Profiles and Command Sets a user account needs to be local to the ACS.  I tried every combination I could think of, including RADIUS attributes, and I could never get authorization to work if there was not a local user account.  Again, the key was creating the Identity Store Sequence.  On several occasions I created a local user account that matched my OTP account, but could never get it to work until I found the information in the ACS 5.1 Migration Guide.


This is not clear in the 5.2 documentation as far as I can tell, but perhaps I overlooked or did not see it.  One can only hope that more detailed examples, like those available for the 4.x version of ACS are in the making.


In any case, it took a while to figure out, but getting it to work was a major accomplishment.


Jim

michael.heer Thu, 02/09/2012 - 01:37
User Badges:

For the people who will get WLC and WCS connected with TACACS to ACS too.


I spend a lot of time trying to get to work. I wanted it to work with tacacs because my wireless authentication is done with radius and I want to split this in reporting and for ease of use cause all other devices also use tacacs. At last I figured out that case sensitive plays a matter but also spaces at the end. For some reason while adding a value in the shell profile in ACS some spaces were already present and then the task did not work... So erase before adding a value..


Regards,


Michael Heer

da.newman Tue, 05/15/2012 - 01:12
User Badges:

I've followed the above discussion and got a WLC 5508 authentication working to ACS 5.2 after spending a longtime determining the problem was caused by case sensitive and additional spaces in the Shell Profile in ACS as reported by Michael Heer above. For reference for anyone who finds this thread with issues getting a WLC and ACS working the below image shows the location of the two issues.


When configuring the shell profile ensure the following:

1) The attribute is lowercase "role1" and not "Role1". (Blue Box)

2) If you select the "value" field you will notice the cursor will jump about 1 quarter across the line (Red Arrow). Ensure you delete these additional spaces before entering anything in this field.


WLC_ACS_shell_profile.png

Hope this helps anyone who got stuck trying to solve this problem like I did.

nathan.ollis Mon, 05/05/2014 - 07:10
User Badges:

Figured I would try this thread first.  I am using ACS 5.1 (OTP tokens) with our WLC's.  I have made sure there are no spaces, exactly as shown.  It was working but now if you login to a WLC for web, it wants you to login for every portion of the page.  It will load the left frame, ask to login, load upper frame, ask for login, etc.  Everytime you click, it asks for login.  Any help with that?

Actions

This Discussion