01-27-2011 07:42 AM - edited 11-18-2020 02:52 AM
This document provides a configuration example of Cisco ACS 5.x (TACACS+) with Cisco Wireless LAN Controller 4400 series (WLC) for Web Authentication.
TACACS+ is a client/server protocol that provides centralized security for users that attempt to gain management access to a router or network access server. TACACS+ provides these AAA services:
· In order to configure TACACS+ in the Cisco WLC controller, you need to complete these steps:
Complete these steps in order to add a TACACS+ Authentication Server:
1. Use the GUI, and go to Security > TACACS+ > Authentication.
2. Add the details of the ACS (tacacs+) server. the IP address of the TACACS+ server and enter the shared secret key. If required, change the default port of TCP/49. The shared secret will be same as defined for WLC in ACS server.
3. Click Apply.
You can accomplish this from CLI using the
config tacacs auth add <Server Index> <IP addr> <port> [ascii/hex] <secret> command:
(Cisco Controller) >config tacacs auth add 1 2.2.2.2 49 ascii cisco123
1. From the GUI, go to Security > TACACS+ > Authorization.
2. Add the IP address of the TACACS+ server and enter the shared secret key. If required, change the default port of TCP/49
3. Click Apply.
You can accomplish this from CLI using the
config tacacs athr add <Server Index> <IP addr> <port> [ascii/hex] <secret> command:
(Cisco Controller) >config tacacs athr add 1 2.2.2.2 49 ascii cisco123
Complete these steps in order to add a TACACS+ Accounting Server:
1. Use the GUI, and go to Security > TACACS+ > Accounting.
2. Add the IP address of the server and enter the shared secret key. If required, change the default port of TCP/49.
3. Click Apply.
This step explains how to configure the AAA order of authentication when there are multiple databases configured. The order of authentication can be local and RADIUS, or local and TACACS. The default controller configuration for order of authentication is local and RADIUS.
Complete these steps in order to configure the order of authentication:
1. From the GUI, go to Security > Priority Order > Management User.
2. Select the Authentication Priority. In this example, TACACS+ has been selected.
3. Click Apply in order for the selection to take place.
You can accomplish this from CLI using the config aaa auth mgmt <server1> <server2> command:
(Cisco Controller) >config aaa auth mgmt tacacs local
This section provides the steps involved in the TACACS+ ACS 5.x Server to create services and custom attributes, and assign the roles to the users or groups.
Complete this step:-
1. Add the Controller management IP address as AAA client with Authentication mechanism as TACACS+ (Cisco IOS).
2. Create a Shell Profile called Permit-WLC under Policy Elements > Authorization and Permissions > Device Administration > Shell Profiles.
3. Under Custom Attributes add the Roles manually with attribute "role1", requirement "Mandatory" and the value "ALL".
4. Create the Access Policies. Edit the Authorization section of the Access Policy, Add a rule that matches Protocol TACACS and NDG:Device Type <WLC>, on that rule under Results set the Shell Profile to be Permit-WLC.
Once it is configured you can test the authentication and confirm with the number of hit counts.
Cisco ACS 5.1 provides policy decisions by using first-match rule tables to evaluate a set of rules. Rule tables contain conditions and results. Conditions can be either simple or compound. Simple conditions consist of attribute operator value and are either true or false. Compound conditions contain more complex conditions combined with AND or OR operators.
The administrator selects simple conditions to be included in a policy. The conditions are displayed as columns in a rule table where the column headings are the condition name, which is usually the name of the attribute. The rules are displayed under the column headings, and each cell indicates the operator and value that are combined with the attribute to form the condition. If ANY appears in a cell, it indicates that no operations or comparisons are performed on that attribute.
Above figure shows a column-based rule table with defined condition types.
Column | Description |
Status | You can define the status of a rule as enabled, disabled, or monitored: Enabled—ACS evaluates an enabled rule, and when the rule conditions match the access request, ACS applies the rule result. Disabled—The rule appears in the rule table, but ACS skips this rule and does not evaluate it.
Monitor Only—ACS evaluates a monitored rule. If the rule conditions match the access request, ACS creates a log record with information relating to the match. ACS does not apply the result, and the processing continues to the following rules. Use this status during a running-in period for a rule to see whether it is needed. |
Name | A descriptive name. You can specify any name that describes the rule's purpose. By default, ACS generates rule name strings <rule-number>. |
Conditions | |
Identity Group | In this example, this is matching against one of the internal identity groups. |
NDG: Location | Location network device group. The two predefined NDGs are Location and Device Type. |
Results | |
Shell Profile | The shell profile is used for device administration-type policies and contains permissions for TACACS+ shell access request, such as Cisco IOS privilege level. |
Hit Counts | Displays the number of times a rule matched an incoming request since the last reset of the policy's hit counters. ACS counts hits for any monitored or enabled rule whose conditions all matched an incoming request. Hit counts for:
Enabled rules reflect the matches that occur when ACS processes requests.
Monitored rules reflect the counts that would result for these rules if they were enabled when ACS processed the requests.
The primary server in an ACS deployment displays the hit counts, which represent the total matches for each rule across all servers in the deployment. On a secondary server, all hit counts in policy tables appear as zeroes. |
NOTE:-
The default rule specifies the policy result that ACS uses when no other rules exist, or when the attribute values in the access request do not match any rules.
Cisco ACS evaluates a set of rules in the first-match rule table as follows:
1. ACS compares the values of the attributes associated with the current access request with a set of conditions expressed in a rule.
2. If the attribute values do not match the conditions, ACS proceeds to the next rule in the rule table.
3. If the attribute values match the conditions, ACS applies the result that is specified for that rule, and ignores all remaining rules.
4. If the attribute values do not match any of the conditions, ACS applies the result that is specified for the policy default rule.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: