Configuring WLC 4402 TACACS+ authentication using Cisco ACS 5.0

[arcadianhealthcisco]

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.

[jimlopresto]

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]

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]

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

[jimlopresto]

Content deleted by author.

[Erick Delgado]

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]

Erick:

Will do.  Thanks for the support.

Jim

[jimlopresto]

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]

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]

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]

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.

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

[nathan.ollis]

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?