| The problem areas of AAA on an IOS router can be categorized as follows based on their implementations: Router management troubleshooting Dial-up networking troubleshooting X-Auth troubleshooting for IPsec Auth-proxy troubleshooting
Router Management Troubleshooting There are two access modes available on the router: character mode or shell exec mode and PPP mode. PPP mode is used for dial-up networking, which is discussed later in this chapter. Shell exec mode is used for router management. As discussed before, TACACS+ protocol is more flexible for router management and provides more granular control. This section examines configuration and troubleshooting in more detail and describes TACACS+ implementation for router management. Login Authentication This section looks into the process of turning on user login authentication on the router followed by a discussion of troubleshooting. Configuration Steps To turn on login authentication (for console, vty line access) follow these steps: Step 1. | Turning on AAA Process
The first step for configuring authentication is to turn on AAA under global configuration mode by executing the command shown in Example 9-3.
Example 9-3. Turning on AAA on the Router Router(config)#aaa new-model Router(config)#
|
| | | Step 2. | Create a local user database.
If there is a small number of users who should have access to the router, you can create the users on the router. A local user database is also recommended to configure for backup methods. Example 9-4 shows that the username Cisco is created in the local database, which may be used for backup when the AAA server is down. Note that a simple unencrypted password is used here for simplicity. We highly recommend using the encryption form for the password with the command username cisco 7 password.
Example 9-4. Creating a Local User Router(config)#username Cisco pass Cisco Router(config)#
|
| Step 3. | Configure AAA server communication parameters on the router.
If you have many users and want to centralize management of users, configure AAA server communication parameters on the router. Example 9-5 shows a router configured with 2 TACACS+ servers. 10.1.1.1 is the primary server because it is entered first in the configuration.
Example 9-5. Defining TACACS+ Server with Backup Router(config)#tacacs-server host 10.1.1.1 key Cisco Router(config)#tacacs-server host 20.1.1.1 key cisco Router(config)#tacacs-server host 20.1.1.1 timeout 30 Router(config)#
|
By default, if the primary server is down or reports an error condition after three tries for five seconds each try, the router sends the authentication request to the second server, in this case, 20.1.1.1. Note that the timeout for the backup server is changed from 5 seconds to 30 seconds in the example. The number of tries may be changed from three as well if desired. Another way of defining the same set of servers is shown in Example 9-6, in which group options for AAA servers are used.
Example 9-6. Defining TACACS+ Server with Backup Router(config)#aaa group server tacacs+ MYTACACS Router(config-sg-tacacs+)#server 10.1.1.1 Router(config-sg-tacacs+)#server 20.1.1.1 Router(config-sg-tacacs+)#exit Router(config)#tacacs-server key cisco
|
| | | Step 4. | Configure AAA client (router) parameters on the AAA server.
For the router to communicate with the AAA server, the NAS (router) must be defined as an AAA client on the AAA server. For this configuration, use the Cisco Secure ACS on Windows as discussed in Chapter 13, "Troubleshooting Cisco Secure ACS on Windows." To configure the AAA client, log in to the ACS browser GUI interface. From the navigation menu, click on NAS Configuration, click on NDG Name (if configured), then click on Add AAA client, which will bring up a window for AAA client definition. Important parameters are NAS IP, Shared Secret, and the Selection of the Protocol to be used. For this example, select TACACS+ for the protocol. Once AAA client is defined, you must click the Submit+Restart button for changes to take effect and to go into the Windows Registry.
| Step 5. | Create a user on the AAA Server.
Log in to ACS Windows, browse to User setup, and define a user. You need only define the password and map the user to an unconfigured group of ACS.
| | | Step 6. | Define the method list for AAA authentication.
Tell the router what to authenticate and how, which is done by configuring the method list. The method list defines the types of authentication that should be performed (for example, login versus PPP or enable authentication). It also defines the types of protocols to be used (TACACS+, local, RADIUS, and so on), and the order in which they should be used. Multiple authentication methods can be configured in the method list as a fall-back mechanism, but only one method will be tried at any one time. Method name is any arbitrary name. It must be applied to a specific interface before any of the defined authentication methods will be performed. However, a default method list is automatically applied to all interfaces. Otherwise, a named method list is explicitly defined. The syntax for defining authentication is as follows:
Router(config)#aaa authentication <service> {default | list-name} method1 [method2...]
Three parameters are required to be configured for authentication. First is the service. There are several options available for service, as shown in Example 9-7.
Example 9-7. Services Available for Authentication Router(config)#aaa authentication ? arap Set authentication lists for arap. attempts Set the maximum number of authentication attempts banner Message to use when starting login/authentication. enable Set authentication list for enable. fail-message Message to use for failed login/authentication. login Set authentication lists for logins. password-prompt Text to use when prompting for a password ppp Set authentication lists for ppp. sgbp Set authentication lists for sgbp. username-prompt Text to use when prompting for a username Router(config)#
|
The most commonly used services are login, enable, and PPP. The example uses login service. The second parameter that must be configured is the name of the method list. Then the actual methods must be configured in sequential order. Example 9-8 shows a method list configured for service login. The name of the method is mylist, and it is configured for TACACS+ and local method for authentication. So, if the TACACS+ server is down or reports an error condition, then try the local user database.
Example 9-8. Sample Output of Defining the Method List Router(config)#aaa authentication login mylist group MYTACACS local Router(config)#
|
| Step 7. | Apply the method list to a interface.
Once a method list is defined successfully, you must apply the method under the interface or line, or authentication will not be triggered. The exception is the default method list. Note that if there are both a default method list and a named method list configured, and the named list is applied to the interface or line, the name list takes precedence over the default method list. Example 9-9 shows that method list mylist created in Example 9-8 is applied under line vty 0 4.
Example 9-9. Method List mylist Being Applied Router(config)#line vty 0 4 Router(config-line)#login authentication mylist Router(config-line)#
|
|
Troubleshooting Steps If the AAA server is configured for authentication and authentication is failing, we suggest using the local user database for authentication. This will help determine if the issue is with the NAS or with the AAA server. If local user authentication fails, you may isolate the problem with the debug aaa authentication command and by using the questions that follow: Step 1. | Is it just a single user failing?
If there are just one or two users failing, the user might be entering either the wrong username or password. To find the cause, search for the string user not found or password validation in the "debug aaa authentication" output.
| Step 2. | Is there multiple user failure?
If there is multiple user failure, there may be misconfiguration on the router. Execute the show run command to verify the config and make sure that you have the aaa authentication login/ppp default method_lists command turned on. Then run debug aaa authentication if needed to isolate the issue further.
| | | Step 3. | Is authentication working for Telnet but not for the console?
If you can authenticate via Telnet but not via console, then you may have not applied the method name under line console. Execute login authentication listname under line con 0.
|
If local user is working, and AAA server is failing the authentication, you may run the test command on the router as shown in Example 9-10 to simulate simple authentication steps to troubleshoot the issue further. In this example, because the RADIUS server is not defined in the configuration, the output shows there is no authoritative response from the server. Example 9-10. Test User Authentication from the Router Router#test aaa authentication group radius user_name user_password legacy Attempting authentication test to server-group radius using radius No authoritative response from any server. Router#
|
Most of the time, AAA server-based authentication can be isolated with the debug aaa authentication and debug tacacs/radius commands, on the router. Sometimes, however, you also may need to analyze the log on the AAA server to isolate a possible misconfiguration on the server. The following discussion shows how to troubleshoot authentication failure that is caused by various reasons. Before we look at some of the possible causes of authentication failure, let's take a look at the successful authentication debug as shown in Example 9-11. Example 9-11. debug Output of Successful User Authentication with TACACS+ Router# 1w0d: TAC+: send AUTHEN/START packet ver=192 id=753768982 1w0d: TAC+: Using default tacacs server-group "tacacs+" list. 1w0d: TAC+: Opening TCP/IP to 10.48.66.102/49 timeout=5 ! Router connected to the TACACS+ Server 1w0d: TAC+: Opened TCP/IP handle 0x81F639C4 to 10.48.66.102/49 1w0d: TAC+: 10.48.66.102 (753768982) AUTHEN/START/LOGIN/ASCII queued 1w0d: TAC+: (753768982) AUTHEN/START/LOGIN/ASCII processed 1w0d: TAC+: ver=192 id=753768982 received AUTHEN status = GETUSER ! Enter Username 1w0d: TAC+: send AUTHEN/CONT packet id=753768982 1w0d: TAC+: 10.48.66.102 (753768982) AUTHEN/CONT queued 1w0d: TAC+: (753768982) AUTHEN/CONT processed 1w0d: TAC+: ver=192 id=753768982 received AUTHEN status = GETPASS ! Enter Password 1w0d: TAC+: send AUTHEN/CONT packet id=753768982 1w0d: TAC+: 10.48.66.102 (753768982) AUTHEN/CONT queued 1w0d: TAC+: (753768982) AUTHEN/CONT processed ! User is successfully authenticated 1w0d: TAC+: ver=192 id=753768982 received AUTHEN status = PASS 1w0d: TAC+: Closing TCP/IP 0x81F639C4 connection to 10.48.66.102/49 Router#
|
NAS does not have the AAA Server configuration If there are multiple user failures, investigate if you accidentally have removed the AAA server entry from the NAS. A quick way to find this out is by executing the command show running-config | include tacacs. If you do not have the TACACS+ server defined, define one and see if the issue is resolved. AAA Server does not have the NAS configured as AAA client You may have AAA Server definition on the NAS (router), but if you do not have the NAS (router) defined as an AAA client on the AAA Server, the server drops the authentication request. Sometimes, you may run into this issue even if you define NAS as your AAA client if the source IP address of the TACACS+ packet changes. Under this circumstance, end users will sometimes be able to authenticate, and at other times, the authentication will fail. This is because if there are multiple paths to the AAA server from NAS, the TACACS+ packet may have different source IP addresses at different times, because the packet may leave from the router through different interfaces. To get around this problem, the best practice is to define a loopback interface on the NAS (router) and force the TACACS+ packet to source always from the loopback interface. This can be achieved with the ip tacacs source-interface Loopback 0 global configuration command on the router. In this command, assume Loopback 0 is created, so that TACACS+ packet always sources from this interface. Even though it is strongly recommended to use a loopback interface under this type of redundant path scenario, you can force the TACACS+ packet to use one of the physical interfaces of the redundant path as the source IP address. Then on the AAA server, define this interface (either the loopback or the physical interface for TACACS+ source IP) as the AAA client in the AAA client table. Otherwise, you must define all interface IP addresses that the router may use to source the TACACS+ packet. Shared secret key mismatch between the NAS and the server The shared secret key is used to encrypt the packet with an MD5 hashing algorithm. If there is a shared secret key mismatch, CS ACS will not trust the NAS. Therefore, it will fail the authentication unless the backup method is configured. On the NAS with debug tacacs, the error condition will be reported and on the ACS Failed Attempt log, you will see clearly the Shared secret key mismatch problem. Connection problem between the NAS and AAA server If there is a connectivity problem between the NAS and the AAA server, all the users will fail. If you run debug tacacs, you will see the "Destination unreachable" message. Run a ping test from the router to the AAA server and see if you can ping. If ping is successful, be sure the outgoing/incoming interface on the router does not have an ACL that may be blocking the TACACS+ (TCP/49) traffic. Also, be sure that there is no Layer 2 or Layer 3 firewall between the NAS and AAA server that may be blocking the communication. A personal firewall or HOST IDS on the AAA server may block the port as well. So, be sure you create the necessary exception. Also, be sure service for TACACS+ is running on the AAA server. User does not exist on the server If user fails with status = FAIL in the debug aaa authentication & debug tacacs, investigate the issue on the CS ACS Server. First look at the Failed Attempt under Reports and Activity and see why the user is failing. Most of the time, this will reveal the reason for the failure. However, to find additional details, you may want to investigate the auth.log after turning on FULL logging, which collects debug information on the CS ACS Server. More details on this can be found in Chapter 13, "Troubleshooting Cisco Secure ACS on Windows." In the auth.log file of CS ACS, search the file by the username you get from Failed Attempts log and see if the user is tagged as an unknown user. This happens when the user does not exist on the CS ACS local database. If the user does not exist on the external user database or CS ACS is not configured with an external user database, you will see the fail message in the auth.log file. User password invalid If the user enters the wrong password, or the password that is configured is not supported, you may receive a "CS Password Invalid message" on the "Failed Attempt" log under "Reports and Activity" of the CS ACS server. On the router debug, you will receive status = FAIL. NAS filter If you have a network access server (NAS) filter configured for the group to which the user is mapped, make sure the authentication request is not blocked by the NAS filter. Note that the NAS filter works with authentication, not with authorization. Hence, if the NAS filter is configured incorrectly on the CS ACS server, the authentication request will not be processed at all. On the router debug you will receive status = FAIL, but on the ACS under the Failed Attempt log, you should see the message related to the NAS filter. If you look at the TCS.log file, which is part of package.cab (more on this in Chapter 13, "Troubleshooting Cisco Secure ACS on Windows"), you will see the user request will come in, but will not be forwarded to the authentication service for further processing. This can be verified by looking at the auth.log where the user request cannot be found. Exec authorization On the NAS (router), if you have exec authorization turned on, but you do not have Shell(exec) checked and "Privilege level" defined under the User/Group setting, authentication will fail. On the router, you will receive a status = FAIL message.
Enable Password Authentication Once the users log in to the router, they can get to the enable mode by entering the enable password. However, sharing the same enable password is unwise for security reasons. Instead, assigning enable passwords based on the individual user name provides more control for access control. In addition to what's configured in the preceding section, Example 9-12 shows the additional configuration required on the router to turn on enable password authentication by the Cisco Secure ACS Server. Example 9-12. Configurations Required for Enable Authentication Router(config)#aaa authentication enable default group MYTACACS enable Router(config)#
|
In this example, enable authentication is performed against the TACACS+ server, and if the TACACS+ server is unavailable, the router's enable password is configured as a back door. This enable password should not be shared with everyone. Also, note that unless the AAA server is down, you cannot get into the enable mode just by entering the enable password. Figure 9-7 shows the configuration required on the Cisco Secure ACS server for enable authentication. Figure 9-7. Configuration Required to Turn on Enable Password Authentication 
In Figure 9-7, "Max Privilege for any AAA Client" is set to "15" and Under the "TACACS+ Enable Passwords" section. "Use Cisco Secure PAP password" is checked. This means the user can use the same password as login for enable authentication, and will have privilege level 15 access to the privilege mode on the router. If you want, you can define a separate password for enable authentication than login. The troubleshooting steps for enabling password authentication are almost the same as those discussed in the Login Authentication section. Additional information that's important and specific to enable password authentication follows: If the "No enable Privilege" is set without defining a privilege for the user on Cisco Secure ACS, you will see the message on the user station as shown in Example 9-13. The CS ACS Failed Attempt will report "CS password invalid." Example 9-13. Test Run Failure for the Enable Password Username: cisco Password: <user password on ACS> Router>enable Password: <enable/user password on ACS> % Error in authentication. Router>
|
On the router, if you run debug tacacs, you will see a message similar to that shown in Example 9-14. Example 9-14. debug tacacs Output for Enable Password Authentication Router#debug tacacs ! Enter enable <privilege level configured under max privilege level on ACS> 1w0d: TAC+: send AUTHEN/START packet ver=192 id=3843638108 1w0d: TAC+: Opening TCP/IP to 10.48.66.102/49 timeout=5 1w0d: TAC+: Opened TCP/IP handle 0x81F2A0D0 to 10.48.66.102/49 1w0d: TAC+: Opened 10.48.66.102 index=1 1w0d: TAC+: 10.48.66.102 (3843638108) AUTHEN/START/LOGIN/ASCII queued 1w0d: TAC+: (3843638108) AUTHEN/START/LOGIN/ASCII processed 1w0d: TAC+: ver=192 id=3843638108 received AUTHEN status = GETPASS ! Enter enable Password 1w0d: TAC+: send AUTHEN/CONT packet id=3843638108 1w0d: TAC+: 10.48.66.102 (3843638108) AUTHEN/CONT queued 1w0d: TAC+: (3843638108) AUTHEN/CONT processed 1w0d: TAC+: ver=192 id=3843638108 received AUTHEN status = FAIL | PASS 1w0d: TAC+: Closing TCP/IP 0x81F2A0D0 connection to 10.48.66.102/49 Router#
|
Note If enable password authentication is configured with RADIUS protocol, you must configure the username $enable$ in the ACS server. This is because with the RADIUS protocol, when the user tries to enter into enable mode, the router generates an authentication request with $enable$ as the username, and the enable password entered by the user as the enable password. When this request arrives at the CS ACS server, it checks enable password for user $enable$. Hence, if user $enable$ is not defined with a common password shared by all users with same privilege level, enable authentication will fail with the following message displayed: "External DB user invalid or bad password" in the Failed Attempt log.
Exec Authorization Exec authorization is used to assign the privilege level to a user either by the AAA server or by the router itself. If configured locally on the router, this privilege level also determines what commands the user may execute. By default, there are three privilege levels on the router. privilege level 1 = non-privileged (prompt is router>), the default level for logging in. privilege level 15 = privileged (prompt is router#), the level after going into enable mode. privilege level 0 = seldom used (prompt is router>), but includes 5 commands: disable, enable, exit, help, and logout. Levels 214 are not used in a default configuration, but commands that are normally at level 15 can be moved down to one of those levels, and commands that are normally at level 1 can be moved up to one of those levels.
Example 9-15 shows the configuration in which snmp-server commands are moved down from privilege level 15 (the default) to privilege level 7. The ping command is moved up from privilege level 1 to privilege level 7. When user backup is authenticated, that user is assigned privilege level 7 by the server and a show privilege command displays "Current privilege level is 7." The user can ping and perform snmp-server configuration in configuration mode. Example 9-15. Authorization exec Command Router# aaa new-model aaa authentication login default group tacacs+ | radius local aaa authorization exec default group tacacs+ | radius local username backup privilege 7 password 0 backup tacacs-server host 10.1.1.40 tacacs-server key cisco radius-server host 10.1.1.40 radius-server key cisco privilege configure level 7 snmp-server host privilege configure level 7 snmp-server enable privilege configure level 7 snmp-server privilege exec level 7 ping privilege exec level 7 configure terminal privilege exec level 7 configure Router#
|
As a logged-in user, to determine the privilege level, use the show privilege command. To determine what commands are available at a particular privilege level for the version of Cisco IOS software that you are using, type a question mark (?) at the command line when logged in at that privilege level. As you can see, if set locally on the router, command authorization relies heavily on the privilege level assigned to the user. However, this can be accomplished with command authorization (instead of relying on the privilege level only) with TACACS+ server. Note that RADIUS does not have command authorization capability. Unlike local privilege-level based authorization, which is based on the router, authorization with external AAA server scales very well. The following section explains how to accomplish the authorization with CS ACS Server. The following are the configuration steps required on the CS ACS on Windows for TACACS+ exec authorization: Step 1. | Enter the username and password.
| Step 2. | In Group Settings, make sure shell/exec is checked, and that 7 has been entered in the privilege level box.
|
The following are the configuration steps required for the Radius Authorization. Step 1. | Enter the username and password.
| Step 2. | In the Group Settings for IETF, optionally check the box [006] Service-Type, and select NAS Prompt from the drop-down list.
| Step 3. | In the Cisco IOS/PIX RADIUS Attributes area, check the [009\001] cisco-av-pair box, and in the rectangular box underneath, enter shell:priv-lvl=7.
|
With exec authorization enabled on the router, when the user uses Telnet or Console to access the router, the user is taken directly to the privilege mode based on the privilege level defined either locally on the router or CS ACS server. Example 9-16 illustrates this behavior for user "Cisco," who is taken directly to the router's privilege mode after Telnet login authentication. Example 9-16. Sample Telnet Login Session When Exec Authorization Is Configured User Access Verification Username: Cisco Password: Router#
|
Before getting into issues that might arise when exec authorization is configured, let's examine a good authentication with exec authorization debug output. Example 9-17 shows debug tacacs+ on the router for a successful user authentication when exec authorization is turned on as shown in Example 9-17. Example 9-17. debug tacacs+ Output of Successful User Authentication with Exec Authorization Turned on Router#debug tacacs 1w0d: TAC+: send AUTHEN/START packet ver=192 id=2766506766 1w0d: TAC+: Using default tacacs server-group "tacacs+" list. 1w0d: TAC+: Opening TCP/IP to 10.48.66.102/49 timeout=5 1w0d: TAC+: Opened TCP/IP handle 0x821E4F30 to 10.48.66.102/49 1w0d: TAC+: 10.48.66.102 (2766506766) AUTHEN/START/LOGIN/ASCII queued 1w0d: TAC+: (2766506766) AUTHEN/START/LOGIN/ASCII processed ! Here Router is asking user to Enter Username 1w0d: TAC+: ver=192 id=2766506766 received AUTHEN status = GETUSER 1w0d: TAC+: send AUTHEN/CONT packet id=2766506766 1w0d: TAC+: 10.48.66.102 (2766506766) AUTHEN/CONT queued 1w0d: TAC+: (2766506766) AUTHEN/CONT processed ! Here Router is asking user to enter Password 1w0d: TAC+: ver=192 id=2766506766 received AUTHEN status = GETPASS 1w0d: TAC+: send AUTHEN/CONT packet id=2766506766 1w0d: TAC+: 10.48.66.102 (2766506766) AUTHEN/CONT queued 1w0d: TAC+: (2766506766) AUTHEN/CONT processed ! Authentication status shows Pass here 1w0d: TAC+: ver=192 id=2766506766 received AUTHEN status = PASS 1w0d: TAC+: Closing TCP/IP 0x821E4F30 connection to 10.48.66.102/49 1w0d: TAC+: using previously set server 10.48.66.102 from group tacacs+ 1w0d: TAC+: Opening TCP/IP to 10.48.66.102/49 timeout=5 1w0d: TAC+: Opened TCP/IP handle 0x81EFB590 to 10.48.66.102/49 1w0d: TAC+: Opened 10.48.66.102 index=1 ! Authorization starts here 1w0d: TAC+: 10.48.66.102 (2142041245) AUTHOR/START queued 1w0d: TAC+: (2142041245) AUTHOR/START processed ! Authorization Pass as shown in the status 1w0d: TAC+: (2142041245): received author response status = PASS_ADD 1w0d: TAC+: Closing TCP/IP 0x81EFB590 connection to 10.48.66.102/49 ! Privilege level 7 is getting assigned by the AAA server 1w0d: TAC+: Received Attribute "priv-lvl=7"
|
The following are some of the common mistakes that you may encounter with the exec authorization: Exec Authorization is not turned on If you do not have the exec authorization turned on, of course the privilege level will not be assigned to the user. So, you may not get the expected behavior. Exec is not checked on the ACS Server If you have the exec configured on the NAS but not on the server, authentication will fail for the user. Privilege level is not configured on the ACS Server Along with having the exec enabled on the Server, you must also configure the privilege level in the group for the users; otherwise, authentication may fail.
Command Authorization You can control the commands the user may execute with command authorization. In addition to configuration for authentication, Example 9-18 shows the configuration needed on the router to turn on command authorization. Example 9-18. Turning on AAA Command Authorization !The following commands turn on command authorization for level 1 Router(config)#aaa authorization commands 1 default group tacacs none !The following command turn on authorization for level 15 Router(config)#aaa authorization commands 15 default group tacacs none !The following command turn on command authorization for config commands Router(config)#aaa authorization config-commands Router(config)#
|
On the ACS Server for command authorization, configure one of the following options except the firstnone: None No authorization for shell commands. Assign a Shell Command Authorization Set for any network device One shell command authorization set is assigned, and it applies to all network devices. Assign a Shell Command Authorization Set on a per Network Device Group Basis Enables you to associate particular shell command authorization sets to be effective on particular NDGs. Per Group Command Authorization Enables you to permit or deny specific Cisco IOS commands and arguments at the group level.
You may also configure the Shared Profile component for command authorization. Work through the steps that follow to configure command authorization on the CS ACS under the group that allows the user to execute only the show users command and to deny the rest of the commands: Step 1. | In Group Setup, under Shell Command Authorization Set, click the Per Group Command Authorization button.
| Step 2. | For Unmatched Cisco IOS commands, click the Deny button.
| Step 3. | Check the Command check box, and in the text box underneath, define show.
| Step 4. | In the Arguments box, type the argument users.
| Step 5. | For Unlisted arguments, click the Deny button.
| Step 6. | Finally click on Submit and Restart.
|
Example 9-19 shows a successful authorization debug command. Example 9-19. debug Output of Successful Command Authorization Router#debug aaa authorization Router#debug tacacs !After the user authentication, user tries to execute show users command, as configured !in aaa authorization commands 1 default group tacacs+ none. *Mar 15 18:21:32: AAA/AUTHOR/CMD: tty3 (4185871454) user='Cisco' *Mar 15 18:21:32: tty3 AAA/AUTHOR/CMD (4185871454): send AV service=shell *Mar 15 18:21:32: tty3 AAA/AUTHOR/CMD (4185871454): send AV cmd=show *Mar 15 18:21:32: tty3 AAA/AUTHOR/CMD (4185871454): send AV cmd-arg=users *Mar 15 18:21:32: tty3 AAA/AUTHOR/CMD (4185871454): send AV cmd-arg= *Mar 15 18:21:32: tty3 AAA/AUTHOR/CMD (4185871454): found list "default" *Mar 15 18:21:32: tty3 AAA/AUTHOR/CMD (4185871454): Method=tacacs+ (tacacs+) *Mar 15 18:21:32: AAA/AUTHOR/TAC+: (4185871454): user=Cisco *Mar 15 18:21:32: AAA/AUTHOR/TAC+: (4185871454): send AV service=shell *Mar 15 18:21:32: AAA/AUTHOR/TAC+: (4185871454): send AV cmd=show *Mar 15 18:21:32: AAA/AUTHOR/TAC+: (4185871454): send AV cmd-arg=users *Mar 15 18:21:32: AAA/AUTHOR/TAC+: (4185871454): send AV cmd-arg= *Mar 15 18:21:32: TAC+: using previously set server 172.18.124.113 from group tacacs+ *Mar 15 18:21:32: TAC+: Opening TCP/IP to 172.18.124.113/49 timeout=5 *Mar 15 18:21:32: TAC+: Opened TCP/IP handle 0x54F26C to 172.18.124.113/49 *Mar 15 18:21:32: TAC+: Opened 172.18.124.113 index=1 *Mar 15 18:21:32: TAC+: 172.18.124.113 (4185871454) AUTHOR/START queued *Mar 15 18:21:33: TAC+: (4185871454) AUTHOR/START processed *Mar 15 18:21:33: TAC+: (4185871454): received author response status = PASS_ADD *Mar 15 18:21:33: TAC+: Closing TCP/IP 0x54F26C connection to 172.18.124.113/49 *Mar 15 18:21:33: AAA/AUTHOR (4185871454): Post authorization status = PASS_ADD Router#
|
Some of the issues that might arise with the command authorization are as follows: Command Authorization not turned on for the correct privilege If the user gets privilege level 10 from the AAA server, but the router has only AAA command authorization turned on for levels 1 and 15, the user will not be authorized for commands on the router. To fix this problem, turn on command authorization for level 10 with command aaa authorization commands 10 default group tacacs none. Cannot command authorize the config commands If you are missing aaa authorization config-commands from the router configuration, the configuration mode command will not be authorized. Misconfiguration on the AAA server If you have the group profile configured incorrectly on the AAA server, the command authorization will fail. One such misconfiguration example is not defining the commands and arguments on the AAA server for the group profile as it is parsed by the router. Defining show run in the group profile will not work, but show running-config will work because that's the full form of the show command. This is how it is parsed and sent to the AAA server by the router. So, make sure to define the commands in the group profile with full form as it is parsed by the router.
Accounting To capture user activity and send it to the AAA server, configure AAA accounting on the router as shown in Example 9-20. Example 9-20. Turning on Accounting for Telnet and Console !The following command will turn on Exec accounting to capture the telnet/console session Router(config)#aaa accounting exec default start-stop !System accounting provides information about all system-level events Router(config)#aaa accounting system default start-stop !The following Command accounting provides information about the EXEC shell commands for !a specified privilege level that are being executed on a network access server. Each !command accounting record includes a list of the commands executed for that privilege !level, as well as the date and time each command was executed, and the user who executed !it. Router(config)#aaa accounting commands 1 default start-stop Router(config)#aaa accounting commands 15 default start-stop
|
Dialup Networking Troubleshooting While TACACS+ protocol is more flexible for router management, RADIUS is more suitable for dialup networking. This section examines configuration and troubleshooting in more detail and describes RADIUS implementation for dialup networking. Authentication and Authorization for Dialup Networking There are two ways the users can dial into the router: using character mode or packet mode. When users dial in with character mode, it is a non-PPP session, just like a hyperterminal dial into the router. This is also called shell mode. In this mode, the user lands on the router itself. With packet mode, users will use dialup networking and log in to the network. In this case, PPP is transparent to the user. When using character mode, configure the router so that users will be challenged for username and password to log in. Example 9-21 shows the configuration needed on the router for PPP authentication and authorization. Example 9-21. The Configuration for Dial Access to an Async Link Dhaka#show running-config Building configuration... Current configuration: ! version 12.2 service timestamps debug datetime localtime service timestamps log uptime no service password-encryption ! hostname Dhaka ! aaa new-model !Define the following line for character mode authentication, like telnet, console !etc for router management aaa authentication login default group radius local !The following line is for packet mode authentication (for dialup network). As the !method name is default, it will be applied automatically to async and ISDN interface. aaa authentication ppp default group radius local !The following statement turns on authorization for packed mode (for dial up !network). This is needed for assigning IP address, DNS Server IP, WINS IP etc. from !the AAA Server. aaa authorization network default group radius local enable password cisco%tac!123 ! interface Ethernet0 ip address 10.1.1.10 255.255.255.0 no ip directed-broadcast no ip mroute-cache ! interface Group-Async1 !You must assign an IP-address to the async interface otherwise, you may run into !routing problem. Here using the same ip address as the Etherenet0 interface. ip unnumbered Ethernet0 no ip directed-broadcast encapsulation ppp no ip mroute-cache async mode interactive ! The following command assigns IP address dynamically using the pool name default !which is configured below. peer default ip address pool default no cdp enable !Following line turns on PPP authentication. Here for simplicity pap is used. In the !production network, it is recommended to use chap pap. ppp authentication pap chap !Grouping line 1-16 group-range 1 16 !For this test setup, only one ip address is defined in the local pool. In production !network, you will have the range of ip address. ip local pool default 10.1.1.30 !This is the default gateway for the router. ip default-gateway 10.1.1.1 ip classless ip route 0.0.0.0 0.0.0.0 10.1.1.1 ! !The following extended access-list is defined on the router, but not applied to any !specific interface. As a reply attribute of authorization packet, this ACL name may be !downloaded from the AAA server, which then will be applied for the specific user. The !source address in the ACL is directly reflected up the pool address defined, from which !users IP address will be assigned. In this example, as 10.1.1.30 is the only ip defined !in the pool, this ip address is allowed to a host 10.1.1.35. ip access-list extended dial_access permit ip host 10.1.1.30 host 10.1.1.35 dialer-list 1 protocol ip permit no cdp run ! radius-server host 10.1.1.40 auth-port 1645 acct-port 1646 key ciscohtts123 ! line con 0 exec-timeout 0 0 password cisco$ard^54 transport input none line 1 16 autoselect during-login autoselect ppp !This statement is needed if user connects to the network in character mode and you !want the user to user to do PPP automatically. autocommand ppp script dialer callback modem InOut transport input all line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password cisco^rea%345 ! end Dhaka#
|
Example 9-22 shows the debug output of successful authentication and authorization. Example 9-22. The debug Output When the Authentication Is Successful Dhaka#debug radius Dhaka#debug aaa authentication Dhaka#debug aaa authorization Dhaka#debug ppp authentication Dhaka#debug aaa per-user Dhaka#debug ppp negotiation Dhaka#show debug General OS: AAA Authentication debugging is on AAA Authorization debugging is on AAA Per-user attributes debugging is on PPP: PPP authentication debugging is on PPP protocol negotiation debugging is on Radius protocol debugging is on Dhaka# Jul 20 08:29:44.006: %LINK-3-UPDOWN: Interface Async1, changed state to up As61 PPP: Using dialer call direction As61 PPP: Treating connection as a callin As61 PPP: Authorization required As61 PAP: I AUTH-REQ id 0 len 15 from "cisco" As61 PAP: Authenticating peer cisco AAA/AUTHEN/PPP (00000061): Pick method list 'default' As61 PPP: Sent PAP LOGIN Request RADIUS(00000061): Storing nasport 1 in rad_db RADIUS: Pick NAS IP for uid=97 tableid=0 cfg_addr=0.0.0.0 best_addr=10.1.1.10 RADIUS/ENCODE(00000061): acct_session_id: 97 RADIUS(00000061): sending RADIUS(00000061): Send Access-Request to 10.1.1.40:1645 id 67, len 96 RADIUS: authenticator C1 54 19 75 55 B5 B1 96 - 73 26 D1 EF 43 83 0A DA RADIUS: Framed-Protocol [7] 6 PPP [1] RADIUS: User-Name [1] 6 "cisco" RADIUS: User-Password [2] 18 * RADIUS: Calling-Station-Id [31] 7 "async" RADIUS: Vendor, Cisco [26] 15 RADIUS: cisco-nas-port [2] 9 "Async1" RADIUS: NAS-Port [5] 6 1 RADIUS: NAS-Port-Type [61] 6 Async [0] RADIUS: Service-Type [6] 6 Framed [2] RADIUS: NAS-IP-Address [4] 6 10.1.1.10 RADIUS: Received from id 21645/67 10.1.1.40:1645, Access-Accept, len 38 RADIUS: authenticator 1B F4 44 9E C4 98 38 AC - C4 DC 24 74 78 20 79 D3 RADIUS: Service-Type [6] 6 Framed [2] RADIUS: Framed-Protocol [7] 6 PPP [1] RADIUS: Framed-IP-Address [8] 6 255.255.255.255 RADIUS(00000061): Received from id 21645/67 As61 PPP: Received LOGIN Response PASS Dhaka#
|
With the authorization turned on, you can download information from the CS ACS. The sections that follow describe that information. Downloading ACL per User Basis Using Filter-id You can restrict what the user can do by using an ACL in two ways: using a filter ID, or using attribute value (AV) pairs. This section examines the configuration needed both on the router and the ACS Server to download the ACL name with filter-id. Example 9-23 shows the configuration needed on the router for the task. Example 9-23. Configuration Needed to Download the ACL Name and Applied on the Router for User Access Dhaka(config)# aaa authorization network default group radius Dhaka(config)# ip access-list extended dial_access Dhaka(config-ext-nacl)# permit ip host 10.1.1.30 host 10.1.1.35
|
Figure 9-8 shows that the access-list name that is defined on the router is defined in the Internet Engineering Task Force (IETF) RADIUS attribute 11. Figure 9-8. Filter ID Definition for Radius 
Example 9-24 shows the ACL name downloaded to the NAS. Example 9-24. The ACL Being Downloaded from ACS Dhaka#debug aaa authentication Dhaka#debug aaa authorization Dhaka#debug ppp authentication Dhaka#debug aaa per-user Dhaka#debug ppp negotiation Dhaka#show debug General OS: AAA Authentication debugging is on AAA Authorization debugging is on AAA Per-user attributes debugging is on PPP: PPP authentication debugging is on PPP protocol negotiation debugging is on Dhaka# *Mar 10 22:36:47.640: As1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 10.1.1.30 *Mar 10 22:36:47.644: As1 AAA/AUTHOR/IPCP: Processing AV service=ppp *Mar 10 22:36:47.644: As1 AAA/AUTHOR/IPCP: Processing AV inacl=dial_access *Mar 10 22:36:47.648: As1 AAA/AUTHOR/IPCP: Authorization succeeded *Mar 10 22:36:47.648: As1 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want 10.1.1.30 *Mar 10 22:36:47.652: As1 IPCP: O CONFNAK [ACKrcvd] id 3 len 10 *Mar 10 22:36:47.656: As1 IPCP: Address 10.1.1.30 (0x0306AB44C936) *Mar 10 22:36:47.996: As1 IPCP: I CONFREQ [ACKrcvd] id 4 len 10 *Mar 10 22:36:48.000: As1 IPCP: Address 10.1.1.30 (0x0306AB44C936) *Mar 10 22:36:48.004: As1 AAA/AUTHOR/IPCP: Start. Her address 10.1.1.30, we want 10.1.1.30 *Mar 10 22:36:48.012: AAA/AUTHOR/IPCP As1 (2638016128): Port='Async1' list='' service=NET *Mar 10 22:36:48.012: AAA/AUTHOR/IPCP: As1 (2638016128) user='filterin' *Mar 10 22:36:48.016: AAA/AUTHOR/IPCP: As1 (2638016128) send AV service=ppp *Mar 10 22:36:48.016: AAA/AUTHOR/IPCP: As1 (2638016128) send AV protocol=ip *Mar 10 22:36:48.020: AAA/AUTHOR/IPCP: As1 (2638016128) send AV addr*10.1.1.30 *Mar 10 22:36:48.020: AAA/AUTHOR/IPCP (2638016128) found list "default" *Mar 10 22:36:48.024: AAA/AUTHOR/IPCP: As1 (2638016128) Method=RADIUS *Mar 10 22:36:48.028: RADIUS: allowing negotiated framed address 10.1.1.30 *Mar 10 22:36:48.032: AAA/AUTHOR (2638016128): Post authorization status = PASS_REPL *Mar 10 22:36:48.036: As1 AAA/AUTHOR/IPCP: Processing AV service=ppp !Access-list name dial_access is downloaded from the AAA Server *Mar 10 22:36:48.040: As1 AAA/AUTHOR/IPCP: Processing AV inacl=dial_access *Mar 10 22:36:48.040: As1 AAA/AUTHOR/IPCP: Processing AV addr=10.1.1.30 *Mar 10 22:36:48.044: As1 AAA/AUTHOR/IPCP: Authorization succeeded *Mar 10 22:36:48.044: As1 AAA/AUTHOR/IPCP: Done. Her address 10.1.1.30, we want 10.1.1.30 *Mar 10 22:36:48.048: As1 IPCP: O CONFACK [ACKrcvd] id 4 len 10 *Mar 10 22:36:48.052: As1 IPCP: Address 10.1.1.30 (0x0306AB44C936) *Mar 10 22:36:48.056: As1 IPCP: State is Open *Mar 10 22:36:48.064: As1 AAA/AUTHOR/PER-USER: Event IP_UP *Mar 10 22:36:48.064: As1 AAA/AUTHOR: IP_UP *Mar 10 22:36:48.068: As1 AAA/PER-USER: processing author params. *Mar 10 22:36:48.072: As1 AAA/AUTHOR: Parse 'interface Async1' *Mar 10 22:36:48.192: As1 AAA/AUTHOR: Parse returned ok (0) !here the ACL is getting applied to the interface *Mar 10 22:36:48.192: As1 AAA/AUTHOR: Parse 'IP access-group dial_access in' *Mar 10 22:36:48.336: As1 AAA/AUTHOR: Parse returned ok (0) *Mar 10 22:36:48.340: As1 AAA/AUTHOR: enqueue peruser IP txt=interface Async1 no IP access-group dial_access in *Mar 10 22:36:48.344: As1 IPCP: Install route to 10.1.1.30 Dhaka#
|
This can be verified by executing the command shown in Example 9-25. Example 9-25. The Async Interface Status Dhaka# show ip interface async 1 Async1 is up, line protocol is up Interface is unnumbered. Using address of Ethernet0 (10.1.1.10) Broadcast address is 255.255.255.255 Peer address is 10.1.1.30 MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set !This is where you can confirm access list "dial_access" being applied. Inbound access list is dial_access, default is not set Proxy ARP is enabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is disabled IP fast switching on the same interface is disabled IP Null turbo vector IP multicast fast switching is disabled IP multicast distributed fast switching is disabled IP route-cache flags are None Router Discovery is disabled IP output packet accounting is disabled IP access violation accounting is disabled TCP/IP header compression is disabled RTP/IP header compression is disabled Probe proxy name replies are disabled Policy routing is disabled Network address translation is disabled Web Cache Redirect is disabled BGP Policy Mapping is disabled Dhaka#
|
Downloading ACL/ROUTES, WINS, and DNS IP Using AV Pair The IETF draft standard specifies a method for communicating vendor-specific information between the NAS and the RADIUS server by using the vendor-specific attribute (attribute 26). Cisco's vendor-ID is 9, and the supported option has vendor-type 1, which is named "cisco-avpair." The format of AV pair is as follows: protocol: attribute sep value *
"Protocol" is a value of the Cisco "protocol" attribute for a particular type of authorization. "Attribute" and "value" is an appropriate attribute-value (AV) pair defined in the Cisco TACACS+ specification. The following are some AV pairs: cisco-avpair= "ip:addr-pool=first" cisco-avpair= "shell:priv-lvl=15" Cisco:Avpair="ip:route#1=15.15.15.16 255.255.255.255 12.12.12.13" Cisco:Avpair="ip:inacl#1=permit icmp 1.1.1.0 0.0.0.255 9.9.9.0 0.0.0.255" Cisco:Avpair="ip:dns-server=10.1.1.1" Cisco:Avpair="ip:wins-server=20.1.1.1"
An example illustrates how to configure ACL on CS ACS, which is then downloaded to NAS (router) using Cisco RADIUS AV pair. Follow this same method to configure and download other attributes such as route, dns-server, etc., to the NAS with AV pair. The difference between this filter-id and AV pair implementation for downloading attributes is that with filter-id, you must define the ACL on the router, whereas with AV pair you can define the ACL on the CS ACS server and download to the router. In both cases, you must have authorization enabled on the router. As part of the authorization reply packet from the CS ACS server, the ACL will be downloaded and installed on the router configuration for the user. Figure 9-9 shows the configuration on the ACS. Figure 9-9. The ACL Definition in the AV Pair 
Troubleshooting steps for PPP authentication are very similar to the login authentication that was discussed in the Login Authentication section. So, for details, refer to the "Troubleshooting Steps" under the "Login Authentication" in the Router Management section. Be aware of the following issues that are specific to dialup networking: RADIUS Server Unreachable If the RADIUS server is unreachable, you will receive the debug message shown in Example 9-26. Example 9-26. Radius Server Unreachable in the debug Dhaka#debug radius Dhaka#debug aaa authentication Dhaka#debug aaa authorization Dhaka#debug ppp authentication Dhaka#debug aaa per-user Dhaka#show debug General OS: AAA Authentication debugging is on AAA Authorization debugging is on AAA Per-user attributes debugging is on PPP: PPP authentication debugging is on Radius protocol debugging is on Dhaka# AAA/AUTHEN/LOGIN (0000002D): Pick method list 'default' RADIUS(0000002D): Send Access-Request to 10.1.1.40:1645 id 16, len 90 RADIUS: authenticator EF 8F 65 E1 E8 C2 16 59 - 82 53 0E B7 6E 0B 26 08 RADIUS: User-Name [1] 6 "cisco" RADIUS: User-Password [2] 18 * RADIUS: Vendor, Cisco [26] 13 RADIUS: cisco-nas-port [2] 7 "tty63" RADIUS: NAS-Port [5] 6 63 RADIUS: NAS-Port-Type [61] 6 Virtual [5] RADIUS: Calling-Station-Id [31] 15 "10.1.10.20" RADIUS: NAS-IP-Address [4] 6 10.1.1.1 !When you have communication problem with the server, you will receive many !retransmit like the one below. RADIUS: Retransmit to (10.1.1.40:1645,1646) for id 21645/16 RADIUS(0000002D): Retransmit id 21645/16 !Finally it will give up. RADIUS: Tried all servers. RADIUS: No valid server found. Trying any viable server RADIUS: Tried all servers. RADIUS/DECODE: parse response no app start; FAIL RADIUS/DECODE: parse response; FAIL Dhaka#
|
Wrong Password If the user enters the wrong password, you will see debug messages as shown in Example 9-27. Example 9-27. User Authentication Failing Due to a Bad Password Dhaka#debug radius Dhaka#debug aaa authentication Dhaka#debug aaa authorization Dhaka#debug ppp authentication Dhaka#debug aaa per-user Dhaka#show debug General OS: AAA Authentication debugging is on AAA Authorization debugging is on AAA Per-user attributes debugging is on PPP: PPP authentication debugging is on Radius protocol debugging is on Dhaka# RADIUS(0000008D): Send Access-Request to 10.1.1.40:1645 id 114, len 96 RADIUS: authenticator 2E 41 E3 D9 80 F1 EB BD - BE 3A 0F 35 13 14 23 37 RADIUS: Framed-Protocol [7] 6 PPP [1] RADIUS: User-Name [1] 6 "cisco" RADIUS: User-Password [2] 18 * RADIUS: Calling-Station-Id [31] 7 "async" RADIUS: Vendor, Cisco [26] 15 RADIUS: cisco-nas-port [2] 9 "Async1" RADIUS: NAS-Port [5] 6 1 RADIUS: NAS-Port-Type [61] 6 Async [0] RADIUS: Service-Type [6] 6 Framed [2] RADIUS: NAS-IP-Address [4] 6 10.1.1.1 RADIUS: Received from id 21645/114 10.1.1.40:1645, Access-Reject, len 32 RADIUS: authenticator 73 09 AC 01 71 BB 3C D3 - 0D 7B 28 44 65 2A BA 08 RADIUS: Reply-Message [18] 12 RADIUS: 52 65 6A 65 63 74 65 64 0A 0D [Rejected??] RADIUS(0000008D): Received from id 21645/114 RADIUS/DECODE: Reply-Message fragments, 10, total 10 bytes As61 PPP: Received LOGIN Response FAIL As61 PAP: O AUTH-NAK id 1 len 26 msg is "Authentication failed" Dhaka#
|
Token password is failing authentication If you are using OTP, be sure to resynchronize the passcode if needed. Also, be sure to configure the PAP authentication on both the client and the NAS, because that's the only password OTP supports. User account password or profile expired If Example 9-27 confirms the failure due to bad password, look at the auth.log file on CS ACS, and for RADIUS, search for the expiration in the profile, such as: Password-Expiration = "24 Jan 2004". Mismatch authentication type If there is a mismatch on authentication type between the NAS and the client, the authentication will fail. For example, if the client is configured to use CHAP (Challenge Handshake Authentication Protocol) only, and NAS is configured with PAP only, authentication will fail. User workstation configured incorrectly If the user workstation misconfiguration is related to password type, you may run into password failure problems. Review the user dialup networking setup, and check for the setup for the parameter such as Requires encrypted password for Windows 95 and 98 client. For Windows NT client, in the Dial-Up Networking window, select the connection name, and then select File > Properties. Select Accept any authentication including clear text to accept both PAP and CHAP passwords. However, if the Accept only encrypted authentication box is checked, the PC accepts only CHAP authentication under the Security Tab. For Windows 2000, in Network and Dial-Up Connections, select the connection name, and then select Properties. On the Security tab, check the settings in the Advanced > Settings > Allow these protocols area and check PAP, CHAP, or MS-CHAP. External user database does not support PPP authentication type CS ACS can be integrated with various external user databases, such as Novel NDS, Microsoft Active Directory (AD), and so on. These databases do not support all authentication types. For instance Microsoft AD does not support CHAP; instead, it supports MS-CHAP. So, if the NAS and client are configured with CHAP only, the external user database, Microsoft AD, will cause the authentication to fail. This failure information can be found in the auth.log file in CS ACS. User exceeded the maximum number of concurrent sessions If the max session is configured and the user reaches the maximum number of concurrent sessions, the user authentication will fail. To fix the problem, for RADIUS, look for this AVP: Maximum-Channels. Adjust the value as appropriate. Service definition for authorization If you are missing service=ppp and related AVPs (protocol=ip and protocol=lcp), your authorization will fail. So be sure to configure these values on the Group Profile. AVPs are downloaded to NAS but not being applied If for debug aaa authorization and debug radius you see the attributes are downloaded to the router but not being applied, you do not have the aaa authorization turned on for PPP on the router. To fix the problem, turn on authorization with command aaa authorization network default group radius on the NAS. Incorrect reply attributes from ACS server
Example 9-28 shows an example of a wrong reply attribute debug. Example 9-28. debug Output for a Wrong Reply Attribute Scenario Dhaka#debug radius Dhaka#debug aaa authentication Dhaka#debug aaa authorization Dhaka#debug ppp authentication Dhaka#debug aaa per-user Dhaka#show debug General OS: AAA Authentication debugging is on AAA Authorization debugging is on AAA Per-user attributes debugging is on PPP: PPP authentication debugging is on Radius protocol debugging is on Dhaka# *Apr 5 23:12:28.228: AAA/AUTHOR/EXEC: Authorization FAILED *Apr 5 23:12:30.228: AAA/MEMORY: free_user (0x612311BC) user='rad_dial' ruser='' port='tty4' rem_addr='408/3241933' authen_type=ASCII service=LOGIN priv=1 *Apr 5 23:12:30.936: %ISDN-6-DISCONNECT: Interface Serial0:0 disconnected from unknown, call lasted 61 seconds *Apr 5 23:12:30.980: %LINK-3-UPDOWN: Interface Serial0:0, changed state to down Dhaka#
|
To fix the problem, configure RADIUS AVP as follows: Frame-Protocol=ppp, Service Type is Framed.
Accounting for Dialup Networking Network accounting provides information for all PPP, SLIP, or ARAP sessions, including packet and byte counts. On the router, network accounting can be turned on with the following command: aaa accounting network default start-stop group radius
X-Auth Troubleshooting for IPsec The Extended Authentication (X-Auth) feature allows the user of the IPsec client to perform user authentication and group authentication. Because group authentication is common for all users of the same group, this per-user basis authentication provides one extra layer of authentication to provide additional security in collaboration with TACACS+ or RADIUS protocols. Extended authentication is negotiated between the Internet Key Exchange (IKE) phase 1 and IKE phase 2. X-Auth was introduced in 12.1(1) T. However, it was not supported in 12.1(1) mainline. Due to some issues with older versions, using 12.1(3) T and above is recommended. Router IPsec configuration remains as it is. Example 9-29 shows that additional configuration needed to turn on AAA authentication. Example 9-29. Configuration Required to Turn on AAA Authentication for X-Auth Dhaka# configure terminal Dhaka(config)# aaa new-model Dhaka(config)# aaa authentication login default local Dhaka(config)# aaa authentication login xauth_list group tacacs+ Dhaka(config)# crypto map test client authentication list xauth_list Dhaka(config)# tacacs-server host 10.1.1.40 key cisco123 Dhaka#
|
On CS ACS, all you need is a username and password to have a valid user defined. Troubleshooting x-auth on the router is the same as shown in the Login Authentication section, so the same steps are not duplicated here. Auth-proxy Troubleshooting Auth-proxy is discussed in greater detail in the "Case Studies" section of Chapter 5, "Troubleshooting an IOS Firewall." The troubleshooting is very similar to that discussed in the preceding section. For auth-proxy, the priv level must be 15 for this to work properly. So, be sure to turn on exec authorization and auth-proxy authorization, and set the priv-level to 15. |
