cc/td/doc/cisintwk/intsolns
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Diagnosing and Troubleshooting AAA Operations

Diagnosing and Troubleshooting AAA Operations

This chapter focuses on diagnosing and troubleshooting negotiations between AAA devices. This section reviews the case study environment and outlines the protocol flows associated with AAA negotiations in the context of this network environment. The subsequent sections focus on specific troubleshooting techniques as follows:

6.1 Overview of Authentication and Authorization Processes

Before jumping immediately into troubleshooting AAA problems, it is useful to review authentication and authorization processes. Figure 6-1 provides the general scenario this case study is built around. The primary elements of this environment are the AAA server, the AAA database, and the NAS.


Figure 6-1: Basic AAA Case Study Environment

The negotiation suggested in Figure 6-1 is expanded in Figure 6-2 which presents the logical flow of the authentication and authorization processes and illustrates the relationship between the elements within the TACACS+ based AAA negotiation. While the network access server (NAS) communicates directly with the AAA server, the AAA server in turn exchanges information with the Oracle database server.


Figure 6-2: Dial Access Authentication and Authorization Flow Diagram

The RADIUS dial-access authentication and authorization illustrated in Figure 6-3 describes RADIUS negotiation between the NAS and the AAA server. User rad_dial is permitted PPP access through EXEC shell (character mode) or autoselect PPP (packet mode).


Figure 6-3: RADIUS Dial Access Authentication and Authorization Process
Note Unlike TACACS+, the authentication and authorization processes are not handled as separate stages in RADIUS-based AAA access control.

Figure 6-4 and Figure 6-5 expand on the basic negotiation flow depicted in Figure 6-2 by illustrating the specific TACACS+ negotiation process associated with particular users, as defined in their respective CSU profiles.


Figure 6-4: TACACS+ Dial Access Authentication and Authorization Session (EXEC Enabled)

The difference in authorization behavior stems from the use of two commands in the AAA server user configurations. The default_cmd=permit command included in the example in Figure 6-4 enables default privilege level 15 commands for user x.

As configured in Figure 6-4, the session for user x depicts a process that involves either a shell initiated or a standard PPP session. The same negotiations are used in initiating shell access to a router.

Both figures depict the stages of dial access authentication and authorization sessions between an access server and an AAA server. The key difference is defined in the CSU user configuration (profiles) included in each illustration. In Figure 6-4, EXEC shell access authorization is permitted while it is not permitted in the illustration depicted in Figure 6-5.


Figure 6-5: TACACS+ Dial Access Authentication and Authorization Session (EXEC Shell Disabled)

The example session illustrated in Figure 6-5 omits the default_cmd=permit AVP and instead includes the autocmd=ppp negotiate AVP disabling EXEC shell access to IOS devices. User y fails any attempt to access the router and receives the message PPP not allowed on this interface as a result of the PPP configuration statement. This distinction provides an element of security, blocking access to routers.

6.2 Troubleshooting AAA Implementation

These sections help you to accomplish the following tasks:

6.2.1 Troubleshooting Methodology Overview

The troubleshooting methodology adopted in this chapter follows these general steps:

    1. Isolating the problem.

    2. Correcting the problem.

    3. Verifying that the trouble is corrected.

The troubleshooting tables presented in "6.3 AAA Troubleshooting Basics" and the example scenarios presented in "6.4 Troubleshooting Scenarios" generally follow this methodology in listing typical symptoms, and provide associated problems and diagnostics measures.

6.2.2 Cisco IOS Debug Command Summary

Output from Cisco IOS debug commands provide a valuable source of information and feedback concerning state transitions and functions within the AAA subsystem environment.

Use the debug commands that follow for capturing AAA-related transitions and functions:

Enabling this debug command sets conditional debugging for a specific user and generates output debugs related to the user. This command is helpful in an enterprise environment for troubleshooting.
Enabling this debug command displays authentication information with TACACS+ and RADIUS client/server interaction.
Enabling this debug command displays authorization information with TACACS+ and RADIUS client/server interaction.
Enabling this debug command displays accounting information with TACACS+ and RADIUS client/server interaction.
Enabling this debug command displays TACACS+ interaction between IOS client and AAA Server.
Enabling this debug command displays RADIUS interaction between the IOS client and the AAA server.

In addition to debug command output gathered directly from devices running Cisco IOS, a Cisco AAA server can be configured to collect important operational diagnostics.

Go to the following link for information regarding configuring and using CSU ACS logs:

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/cs_unx/csu23rg/troubles.htm

6.3 AAA Troubleshooting Basics

AAA operational diagnostic activity for access environments is divided into the following basic areas:

These three areas can be associated with eight underlying diagnostic situations which are addressed in the following subsections:

The following sections address each of the diagnostic topics separately. Detailed scenarios are provided in "6.4 Troubleshooting Scenarios."

The diagnostics summaries address the troubleshooting process using three basic stages:

    1. Identifying symptoms

    2. Isolating problems

    3. Resolving problems

Each diagnostic table includes suggestions for identifying and isolating problems. Diagnostic information is provided in "6.4 Troubleshooting Scenarios." Specific diagnostic output is included to illustrate how network entities react to failures and how to discern specific failures.

Note Some of the symptoms described in the following tables can be caused by a variety of problems other than AAA issues. Because this case study focuses on AAA-based security topics, the problems and diagnostics provided here focus on AAA issues.

6.3.1 Troubleshooting Dial-Based Local Authentication

The following symptoms are addressed in separate tables in this section:


Table 6-1: Single User Failure; Individual Dial-in User Connection Fails
Problem Suggested Diagnostic Steps

User entered invalid username or password.

    1. To verify local account, enter:

    <NAS>#debug aaa authentication
Test login with username/password.
Look for "user not found" or "password validation" failure.

    2. If user is not found, add the user. If password validation failure, reenter login with username and password combination.


Table 6-2: Multiple User Failure; All Dial-in Users Unable to Connect to NAS
Problem Suggested Diagnostic Steps

AAA behavior configured incorrectly in NAS.

    1. Enter this diagnostic command in NAS:

    <NAS>#debug aaa authentication

    2. To verify local authentication is configured correctly, enter:

    <router>#show running-config

    3. Verify inclusion of one of these commands:

aaa authentication login default local

or
aaa authentication login ppp default local

Shell initiated PPP session passes, but is torn down.

    1. Enter this diagnostic command in NAS:

    <NAS>#debug aaa authentication

    2. To verify AAA is configured correctly in NAS, enter:

    <NAS>#show running-config

    3. Verify inclusion of this command:

aaa authentication ppp default if-needed local

6.3.2 Troubleshooting Dial-Based Server Authentication

The following symptoms are addressed in separate tables in this section:


Table 6-3: Single User Failure; Individual User Unable to Make Connection (RADIUS and TACACS+)
Problem Suggested Diagnostic Steps

User name not in server database.

    1. To verify user is in database, enter:

    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username

User entered password incorrectly.

    1. Verify password case-sensitivity.

    2. Monitor user activity in AAA server:

    <CSUserver>$tail -f /var/log/csuslog|grep username

    3. Review csuslog file for errors (for example, if user is configured for OTP, verify PASSCODE is accepted from OTP server.

    4. Reset user password or synchronize PASSCODE if needed.

User profile configured incorrectly. The error message "bad method for user" reported in csuslog file.

    1. To verify user profile is programmed with correct password type, enter:

    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username

    

    	2. Verify user profile privilege is sufficient to perform task.
    

    	3. Verify profile is configured for correct password type. For example, PAP for OTP.
    





 User account disabled due to too many failed logins.


    

    	1. To view user profile, enter:
    



    <CSUserver>$/opt/ciscosecure/utils/bin/ViewProfile -p 9900 -u username

    

    	2. Verify that the profile is not disabled. If it is disabled, compare set server current-failed-login counters to max failed login setting in CSU.cfg file.
    

    	3. If these attributes are the same, reset user profile status to enabled and reset the set server current-failed-login counter by using the web-based administration utility.
    





 User account password or profile expired.


    

    	1. To view profile, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username
 

    

    	2. For TACACS+: Look for expiration in profile, such as:
    


expires = "24 Jan 2000"



    

    	3. For RADIUS: Look for expiration in profile, such as:
    


Password-Expiration = "24 Jan 2000"





 User workstation configured incorrectly.


    

    	1. Review user dialup networking setup.
    

    	2. To review user profile, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username
 

    

    	3. Check for setup for parameter such as "Requires encrypted password."
    





 User exceeded the maximum number of concurrent sessions.


 To review user profile, enter:


    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username
 

 For TACACS+, look for this AVP: 

max-sessions



 For RADIUS, look for this AVP: 

Maximum-Channels















  

Table 6-4: Multiple User Failure; All Dial-in Users Unable to Connect to NAS (RADIUS and TACACS+)




Problem
Suggested Diagnostic Steps



 Connection between NAS and AAA server is down.


 Verify network connectivity between NAS and AAA server. Enter these diagnostic commands in NAS:


    <NAS>#show tacacs
<NAS>#debug tacacs
<NAS>#debug radius
<NAS>#ping CSU-server-name



 TACACS+ or RADIUS key incorrect in NAS or AAA server.


 Review NAS and CSU configurations for shared secret.


In NAS, enter: 




    <NAS>#show running-config
 

In AAA server, enter:




    <CSUserver>$grep NAS-IP-Address /opt/ciscosecure/config/CSU.cfg
 
<CSUserver>$tail -f /var/log/csuslog
 



 Maximum number of users exceeded.


    

    	1. Verify license key is entered correctly in AAA server. Enter the following commands at the CSUserver:
    



    <CSUserver>$grep license-key /opt/ciscosecure/config/CSU.cfg

 


    

    	2. To review expiration date of license key, enter:
    



    <CSUserver>$grep license-key /var/log/csuslog



 Group profile password type does not match type specified in NAS group-async or dialer interface configuration (for example, PPP authentication PAP).


    

    	1. To review NAS configuration, enter:
    



    <NAS># show running-config
 

    

    	2. Verify group-async or dialer interface is configured with correct password type.  For example, for OTP, PAP must be specified.
    

    	3. Verify group profile matches group-async or dialer interface configuration in NAS.
    





 Shell initiated PPP session passes, but is torn down.


    

    	1. Enter this diagnostic command in NAS:
    



    <NAS>#debug aaa authentication
 

    

    	2. To verify correct AAA configuration is configured in NAS, enter:
    



    <NAS>#show running-config
 

    

    	3. Verify these commands are included in the NAS configuration:
    


aaa authentication ppp default if-needed tacacs+



or



aaa authentication ppp default if-needed radius















 6.3.3 Troubleshooting Dial-Based Local Authorization


 The following symptoms are addressed in separate tables in this section:



  

Table 6-5: User Cannot Start PPP




Problem
Suggested Diagnostic Steps



 User client configuration error.


 Refer to MS troubleshooting chapter:


http://support.microsoft.com/support/kb/articles/Q130/0/79.asp?LNG=ENG&SA=ALLKB  
















  

Table 6-6: Network Authorization Fails




Problem
Suggested Diagnostic Steps



 Attribute-value pairs (AVPs) not assigned1.


    

    	1. Enter this diagnostic command in NAS:
    



    <NAS>#debug aaa authorization
 

    

    	2. To verify AAA is configured correctly in NAS, enter:
    



    <NAS>#show running-config
 

    

    	3. Verify inclusion of this command:
    


aaa authorization exec default local









1AAA authorization only supported on shell sessions with local accounts.






  

Table 6-7: Unable to Access Specific Host or Network Service 




Problem
Suggested Diagnostic Steps



 Access list assigned to user.


    

    	1. Verify local account not restricted with access-class AVP:
    



    <NAS>#show running-config
 

    

    	2. Enter these NAS commands to determine whether access list is assigned to user:
    



    <NAS>#show caller user userid detail
<NAS>#show line
 

    

    	3. To review access list with this NAS command, enter:
    



    <NAS>#show access-list ACL-number













  

Table 6-8: Multilink Fails




Problem
Suggested Diagnostic Steps



 User profile restricted.


 To verify user account is not restricted by inclusion of max-links AVP, enter:


    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username













 6.3.4 Troubleshooting Dial-Based Server Authorization


 The following symptoms are addressed in separate tables in this section:



  

Table 6-9: Multiple Users Cannot Start PPP (RADIUS and TACACS+)




Problem
Suggested Diagnostic Steps



 AAA authorization configured incorrectly in NAS.


    

    	1. Enter this diagnostic command in NAS:
    



    <NAS>#debug aaa authorization
 

    

    	2. To verify AAA is configured correctly in NAS, enter:
    



    <NAS>#show running-config
 

    

    	3. Verify inclusion of this command:
    


aaa authorization network default group tacacs+



or 



aaa authorization network default group radius





 Does not have PPP service assigned.


    

    	1. To view group profile, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname
 

    

    	2. For TACACS+, verify the following commands are assigned to group:
    


service=ppp


protocol=lcp


protocol=ip



    

    	3. For RADIUS, verify the following commands are assigned to group:
    


Service-Type=Framed


Framed-Protocol=ppp





 Group lacks shell service assigned (EXEC shell-initiated PPP session only).


    

    	1. To view group profile, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname
 

    

    	2. For TACACS+, verify the following command is assigned to group:
    


service=shell



    

    	3. For RADIUS, verify the following command is assigned to group:
    


User-Service-Type (Shell-User)















  

Table 6-10: Network Authorization Fails (RADIUS and TACACS+)




Problem
Suggested Diagnostic Steps



 AVPs not assigned.


    

    	1. Enter this diagnostic command in NAS:
    



    <NAS>#debug aaa authorization
 

    

    	2. To verify AAA is configured correctly in NAS, enter:
    



    <NAS>#show running-config
 

    

    	3. Verify inclusion of this command:
    


aaa authorization network default group tacacs+



or



aaa authorization network default group radius















  

Table 6-11: User or Group Members Unable to Access Specific Host or Network Service (RADIUS and TACACS+)




Problem
Suggested Diagnostic Steps



 Access list assigned to user.


    

    	1. To view group profile, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname
 

Verify group account not restricted with inacl AVP. 




    

    	2. Enter these NAS commands to determine whether access list is assigned to user:
    



    <NAS>#show caller user userid detail
<NAS>#show line
 

    

    	3. Review access list with this NAS command:
    



    <NAS>#show access-list ACL-number













  

Table 6-12: Multilink Fails (TACACS+)




Problem
Suggested Diagnostic Steps



 User or group profile lacks proper AVP.


    

    	1. To verify group account includes protocol=multilink AVP assigned, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname
 

    

    	2. Review profile for load-threshold AVP and whether it is configured properly.
    





 User or group profile restricted.


 To verify group account not restricted with max-links AVP, enter:


    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname
 













  

Table 6-13: Multilink Fails (RADIUS)




Problem
Suggested Diagnostic Steps



 User or group profile lacks proper AVP.


 To verify group account includes framed-protocol=multilink AVP assigned, enter:


    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname
 



 User or group profile restricted.


 To verify group account not restricted with max-links AVP, enter:


    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname
 













  

Table 6-14: Session Fails to Disconnect After Expected Idle Timeout (TACACS+)




Problem
Suggested Diagnostic Steps



 The idletime AVP not configured on group profile.


 To verify group account includes idletime AVP assigned, enter:


    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname
 













  

Table 6-15: Session Fails to Disconnect After Expected Idle Timeout (RADIUS)




Problem
Suggested Diagnostic Steps



 The Idle-Timeout AVP not configured on group profile.


 To verify group account includes Idle-Timeout AVP assigned, enter:


    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname













  

Table 6-16: No EXEC Shell for TACACS+




Problem
Suggested Diagnostic Steps



 User or group lacks service=shell AVP assigned.


 To verify service=shell is assigned to user or group, enter:


    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname
 
<CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username













  

Table 6-17: No EXEC Shell for RADIUS




Problem
Suggested Diagnostic Steps



 User or group does not have User-Service-Type AVP assigned.


 To verify User-Service-Type (Shell-User) is assigned to user or group, enter:


    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g groupname
 
<CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username













  

Table 6-18: Cannot Start Concurrent Sessions (TACACS+)




Problem
Suggested Diagnostic Steps



 User exceeds the maximum number of concurrent sessions.


    

    	1. To review the user profile, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username
 

    

    	2. Look for the following AVP:
    


server max sessions















  

Table 6-19: Cannot Start Concurrent Sessions (RADIUS)




Problem
Suggested Diagnostic Steps



 User exceeds the maximum number of concurrent sessions.


    

    	1. To review the user profile, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username
 

    

    	2. Look for the following AVP:
    


Maximum-Channels















 6.3.5 Troubleshooting Router-Based Local Authentication


 The following symptoms are addressed in separate tables in this section:



  

Table 6-20: Single User Failure; Individual Dial-in User Connection Fails




Problem
Suggested Diagnostic Steps



 User entered invalid username or password.


    

    	1. To verify local account, enter:
    



    <router>#debug aaa authentication
 

    

    	2. Test login with username/password.
    

    	3. Look for user not found or password validation failure. 
    















  

Table 6-21: Multiple User Failure; All Dial-in Users Unable to Connect to Router




Problem
Suggested Diagnostic Steps



 AAA behavior configured incorrectly in router.


    

    	1. Enter this diagnostic command in router:
    



    <router>#debug aaa authentication
 

    

    	2. To verify local authentication is configured correctly, enter:
    



    <router>#show running-config
 

    

    	3. Verify inclusion of this command:
    


aaa authentication login/ppp default local















  

Table 6-22: Users Can Access Router by Using Console or VTY, but Not Both




Problem
Suggested Diagnostic Steps



 Incorrect AAA configuration in router.


    

    	1. Enter this diagnostic command in router:
    



    <router>#debug aaa authentication
 

    

    	2. To verify AAA is configured correctly in router, enter:
    



    <router>#show running-config
 

    

    	3. Verify method used for console authentication matches VTY method.
    



 For example:


  • AAA configuration:
    


aaa authentication login listname group tacacs+



  • Console line configuration:
    


line con 0


login authentication listname



  • VTY line configuration:
    


line vty 0 4


login authentication listname















 6.3.6 Troubleshooting Router-Based Server Authentication


 The following symptoms are addressed in separate tables in this section:



  

Table 6-23: Single User Failure; Individual User Unable to Make a Connection




Problem
Suggested Diagnostic Steps



 User name not in server database.


    

    	1. To verify user is in database, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username



 User entered password incorrectly.


    

    	1. Verify password case sensitivity.
    

    	2. To monitor user activity in AAA server, enter:
    



    <CSUserver>$tail -f /var/log/csuslog|grep username
 

    

    	3. Review csuslog file for errors.
    





 User profile configured incorrectly. The error message "bad method for user" reported in csuslog file.


    

    	1. To verify user profile is programmed with correct password type, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username

    

    	2. Verify user profile privilege is sufficient to perform task.
    

    	3. Verify profile is configured for correct password type.  For example, DES or clear text.
    





 User account disabled due to too many failed logins.


 


    

    	1. To view user profile, enter:
    



    <CSUserver>$/opt/ciscosecure/utils/bin/ViewProfile -p 9900 -u username

    

    	2. Verify that the profile is not disabled. If it is disabled, compared set server current-failed-login counters to max failed login setting in CSU.cfg file.
    

    	3. If these attributes are the same, reset user profile status to enabled and reset the set server current-failed-login counter by using the web-based administration utility.
    





 User account password or profile expired.


    

    	1. To view profile, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username
 

    

    	2. Look for expiration in profile, such as:
    



expires = "24 Jan 2000"






 User exceeds the maximum number of concurrent sessions.


    

    	1. To review the user profile, enter:
    



    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u username
 

    

    	2. Look for the following AVP:
    



server max sessions
















  

Table 6-24: Multiple User Failure; All Dial-In Users Unable to Connect to the Router




Problem
Suggested Diagnostic Steps



 Connection between router and AAA server down.


 


 Verify network connectivity between router and AAA server. Enter these diagnostic commands in router:


    <router>#show tacacs
<router>#debug tacacs
<router>#debug radius
<router>#ping CSU-IP-address



 TACACS+ key incorrect in router or AAA server.


 Review router and CSU configurations for shared secret.


In the router, enter: 




    <router>#show running-config
 

In the AAA server, enter:




    <CSUserver>$grep router-IP-address /opt/ciscosecure/config/CSU.cfg



 Maximum number of users exceeded.


    

    	1. Verify license key is entered correctly in AAA server. Enter the following commands at the CSUserver:
    



    <CSUserver>$grep license-key /opt/ciscosecure/config/CSU.cfg
 

    

    	2. To review the expiration date of the license key, enter:
    



    <CSUserver>$grep license-key /var/log/csuslog













  

Table 6-25: Users Pass Authentication on Console or VTY, but Not Both




Problem
Suggested Diagnostic Steps



 Incorrect AAA configuration in router.


    

    	1. Enter this diagnostic command in router:
    



    <router>#debug aaa authentication
 

    

    	2. To verify AAA is configured correctly in router, enter.
    



    <router>#show running-config
 

    

    	3. Verify method used for console authentication matches VTY method.
    



 For example:


  • AAA configuration:
    


aaa authentication login listname group tacacs+



  • Console line configuration:
    


line con 0


login authentication listname



  • VTY line configuration:
    


line vty 0 4


login authentication listname















 6.3.7 Troubleshooting Router-Based Local Authorization


 The following symptoms are addressed in separate tables in this section:



  

Table 6-26: User Fails Router Command




Problem
Suggested Diagnostic Steps



 AAA configuration error.


    

    	1. Enter this diagnostic command in router to determine method of authorization and failure:
    



    <router>#debug aaa authorization
 

    

    	2. To verify AAA is configured correctly in router, enter:
    



    <router>#show running-config
 

 Example:


 If aaa authorization commands is used, ensure method specified is local.




 User profile lacks appropriate privilege level to perform command.


 To review privilege configuration in router, enter:


    <router>#show running-config
 

 Example:


 Cisco IOS command aaa authorization commands 15 default local is used, but user does not have a corresponding privilege level assigned.




 User profile lacks appropriate enable level to perform command.


 To review enable privilege level configuration in router, enter.


    <router>#show running-config
 

 Example of relevant Cisco IOS commands:

aaa authentication enable default local


enable 15 secret


enable 10 secret2



 In this example, users at enable level 10 cannot perform privilege level 15 commands.














  

Table 6-27: User Disconnected After Entering a Password




Problem
Suggested Diagnostic Steps



 Authorization failed service. Looks like an authentication problem, but is an authorization failure.


 To review AAA configuration, enter:


    <router>#show running-config
 

 If aaa authorization exec command specifies method other than local, user fails shell access.


 For example, aaa authorization exec default tacacs+ results in local user failing authorization.














  

Table 6-28: Users Access Incorrect Privilege Level Commands




Problem
Suggested Diagnostic Steps



 AAA behavior incorrectly configured.


    

    	1. Enter this diagnostic command in router to determine level of command authorization:
    



    <router>#debug aaa authorization
 

    

    	2. To review AAA configuration in router, enter:
    



    <router>#show running-config
 

    

    	3. Verify AAA configured properly in router.
    



 For example:


aaa authorization commands 15 default local
















  

Table 6-29: Router User Receives Error Message Stating "This Line Not Allowed to Run PPP and is Disconnected"




Problem
Suggested Diagnostic Steps



 The autocommand ppp negotiate command assigned to user.


    

    	1. To review correct configuration is configured in router, enter:
    



    <router>#show running-config
 

Look for autocommand ppp negotiate command assigned to user.




    

    	2. Delete autocommand ppp negotiate if appropriate.
    















 6.3.8 Troubleshooting Router-Based Server Authorization


 The following symptoms are addressed in separate tables in this section:



  

Table 6-30: User Fails Router Command




Problem
Suggested Diagnostic Steps



 AAA configuration error.


    

    	1. Enter this diagnostic command in router to determine method of authorization and failure:
    



    <router>#debug aaa authorization
 

    

    	2. To review AAA configuration in router, enter:
    



    <router>#show running-config
 

 Example:


 If aaa authorization commands is used, ensure method specified is tacacs+.




 User profile lacks appropriate privilege level to perform command.


 To view user profile for appropriate priv-lvl=x AVP, enter:


    <CSUserver>$/opt/ciscosecure/utils/bin/ViewProfile -p 9900 -u username



 User profile lacks appropriate enable privilege level to perform command.


 To view user profile for appropriate enable privilege level, enter:


    <CSUserver>$/opt/ciscosecure/utils/bin/ViewProfile -p 9900 -u username
 

 For example: 


privilege = des "********" 15




 














  

Table 6-31: User Disconnected After Entering Password




Problem
Suggested Diagnostic Steps



 Authorization failed service.


 To review AAA configuration, enter:


    <router>#show running-config
 

 If aaa authorization exec command specifies method other than TACACS+, user fails shell access.


 For example, aaa authorization exec default local results in TACACS+ user failing authorization.














  

Table 6-32: Users Access Incorrect Privilege Level Commands




Problem
Suggested Diagnostic Steps



 AAA behavior incorrectly configured.


    

    	1. Enter this diagnostic command in router to determine level of command authorization:
    



    <router>#debug aaa authorization
 

    

    	2. To verify AAA is configured correctly in router, enter
    



    <router>#show running-config
 

Example of relevant Cisco IOS command:


aaa authorization commands 15 default group tacacs+






 User profile configured incorrectly.


 To view user profile for appropriate priv-lvl=x AVP, enter:


    <CSUserver>$/opt/ciscosecure/utils/bin/ViewProfile -p 9900 -u username













  

Table 6-33: Router User Receives Error Message Stating "This Line Not Allowed to Run PPP and is Disconnected"




Problem
Suggested Diagnostic Steps



 The autocommand ppp negotiate AVP assigned to user.


    

    	1. To view user profile for inclusion of autocommand ppp negotiate AVP assigned to user, enter:
    



    <CSUserver>$/opt/ciscosecure/utils/bin/ViewProfile -p 9900 -u username
 

    

    	2. Delete autocommand ppp negotiate if appropriate.
    















  

Table 6-34: Router User Unable to Initiate Shell Session with Router




Problem
Suggested Diagnostic Steps



 Lack of service=shell AVP; user sees "Authorization failed service" error message.


 To view user profile for inclusion of service=shell AVP, enter:


    <CSUserver>$/opt/ciscosecure/utils/bin/ViewProfile -p 9900 -u username













  

Table 6-35: AVPs Not Working on Console Port




Problem
Suggested Diagnostic Steps



 Feature is not supported on console ports.


 None. Feature not supported.














 6.4 Troubleshooting Scenarios

 
 The following example troubleshooting scenarios elaborate the process of diagnosing, correcting, and testing several problems addressed in "6.3 AAA Troubleshooting Basics": 



 6.4.1 Isolating Incorrect TACACS+ Key in NAS or AAA Server (TACACS+ Dial-Based Server Authentication)


 This scenario focuses on a server-authentication failure for a dial-based connection and provides a statement of a symptom, suggests a specific problem, and summarizes diagnostic steps. Diagnostics include output from relevant debug commands and other troubleshooting tools. See Table 6-4 for additional related problems.



Symptom   Multiple user failure; all dial-in users unable to connect to NAS. See Table 6-4.



Step 1	 Gather general debug command information from the NAS. The following output is from a debug aaa authentication command executed on a NAS. The last line of this debug output shows the failure expressed for user dial_tac.


088189: Jan 27 18:37:22.972 CST: AAA/MEMORY: create_user (0x61D7A2E0) user='' ruser='' port='tty51' rem_addr='172.22.2.3' authen_type=ASCII service=LOGIN priv=1
088190: Jan 27 18:37:22.976 CST: AAA/AUTHEN/START (953379418): port='tty51' list= =30356 25154
088203: Jan 27 18:37:26.216 CST: TAC+: ver=192 id=3035625154 received AUTHEN status = GETPASS
088204: Jan 27 18:37:26.216 CST: AAA/AUTHEN (3035625154): status = GETPASS
088205: Jan 27 18:37:30.337 CST: AAA/AUTHEN/CONT (3035625154): continue_login (user='dial_tac')
088206: Jan 27 18:37:30.337 CST: AAA/AUTHEN (3035625154): status = GETPASS
088207: Jan 27 18:37:30.337 CST: AAA/AUTHEN (3035625154): Method=ADMIN (tacacs+)
088208: Jan 27 18:37:30.337 CST: TAC+: send AUTHEN/CONT packet id=3035625154
088209: Jan 27 18:37:30.637 CST: TAC+: ver=192 id=3035625154 received AUTHEN status = FAIL
 


Step 2	 Enter the following command to assess warnings and errors reported in the AAA server log file:


<CSUserver>$tail -f /var/log/csuslog
 

 The AAA server log file reports the following warning when no key is specified (indicating that there is no encryption key):


Jan 27 18:35:17 coachella CiscoSecure: WARNING - Insecure configuration: No encryption key for NAS <default>

 



Step 3	 Review NAS configurations for shared secret configuration. To obtain the NAS configuration, enter:


<NAS>#show running-config
 

 The following configuration fragment specifies the TACACS+ server and key. In this case, the key is bobbit.


tacacs-server host 172.22.53.201 key bobbit
 

 Review the AAA server configuration for the corresponding server shared secret configuration. View the CSU.cfg file with vi (or a similar tool):


<CSUserver>$vi /opt/ciscosecure/config/CSU.cfg
 

 Find the key configuration in the CSU.cfg AAA server configuration file and review it for the NAS specification. In this example, this configuration is missing.


NAS config_nas_config =
        {
                {
                "172.22.53.201",
                "",
 

 If the key is properly configured, it appears between the quotation marks following the IP address specification. In this case, the key is missing. Because it is not specified in the AAA server configuration file, users' access is blocked.



Step 4	 Update key specifications and restart the AAA server. Verify successful dialup operation.





 



 6.4.2 Isolating Invalid User Password (TACACS+ Dial-Based Server Authentication)


 This scenario focuses on a server-authentication failure for a dial-based connection and provides a statement of a symptom, suggests a specific problem, and summarizes diagnostic steps. Diagnostics include output from relevant debug commands and other troubleshooting tools. See Table 6-3 for additional related problems.



Symptom   Single user failure; individual dial-in user unable to connect to NAS. See Table 6-3.



Step 1	 Gather general debug command information from the NAS. The following output is from a debug aaa authentication command executed on a NAS. This command results in a stream of diagnostic output. 


 The last line in the following output shows the AAA authentication request sent to AAA server for user dial_tac:


092852: Jan 27 22:19:06.713 CST: AAA/AUTHEN (543609479): status = GETPASS
092853: Jan 27 22:19:07.985 CST: AAA/AUTHEN/CONT (543609479): continue_login (user='dial_tac')
 

 The NAS receives FAIL from AAA server for user:


092854: Jan 27 22:19:07.985 CST: AAA/AUTHEN (543609479): status = GETPASS
092855: Jan 27 22:19:07.985 CST: AAA/AUTHEN (543609479): Method=ADMIN (tacacs+)
092856: Jan 27 22:19:07.985 CST: TAC+: send AUTHEN/CONT packet id=543609479
092857: Jan 27 22:19:08.185 CST: TAC+: ver=192 id=543609479 received AUTHEN status = FAIL
092858: Jan 27 22:19:08.185 CST: AAA/AUTHEN (543609479): status = FAIL
 

 The user session is torn down and AAA process is freed:


092859: Jan 27 22:19:10.185 CST: AAA/MEMORY: free_user (0x61D87A70) user='dial_tac' ruser='' port='tty51' rem_addr='172.22.2.3' authen_type=ASCII service=LOGIN
priv=1
 


Step 2	 Enter the tail command to assess warning and errors reported in the AAA server log file:


<CSUserver>$tail -f /var/log/csuslog
 

 In this case, the AAA server log reports an incorrect password for user dial_tac:


Jan 27 22:19:08 coachella CiscoSecure: NOTICE - Authentication - Incorrect password; [NAS = 172.22.63.1, Port = tty51, User = dial_tac, Service = 1, Priv = 1]
Jan 27 22:19:08 coachella CiscoSecure: INFO - Profile: user = dial_tac {
Jan 27 22:19:08 coachella set server current-failed-logins = 1






Note Following the failure, the current-failed-login counter increments. This counter is described in Table 6-3.





Step 3	 If the user does not exist in the database (but should), create a new user, or provide feedback if password or login were entered incorrectly by the user.





 



 6.4.3 Isolating Non-Existent User (TACACS+ Dial-Based Server Authentication)


 This scenario focuses on a server-authentication failure for a dial-based connection and provides a statement of a symptom, suggests a specific problem, and summarizes diagnostic steps. Diagnostics include output from relevant debug commands and other troubleshooting tools. See Table 6-3 for additional related problems.



Symptom   Single user failure; individual dial-in user unable to connect to NAS. See Table 6-3.



Step 1	 Gather general debug command information from the NAS. The following output is from a debug aaa authentication command executed on a NAS. 


 The following output fragment shows the AAA process starting on NAS.


092794: Jan 27 22:15:39.132 CST: AAA/MEMORY: create_user (0x61D87A70) user='' ruser='' port='tty51' rem_addr='172.22.2.3' authen_type=ASCII service=LOGIN priv=1
092795: Jan 27 22:15:39.132 CST: AAA/AUTHEN/START (3576082779): port='tty51' list='INSIDE' action=LOGIN service=LOGIN
 

 GETPASS is sent to AAA server for verification for user dial_test:


092806: Jan 27 22:15:41.132 CST: AAA/AUTHEN/START (3285027777): Method=ADMIN (tacacs+)
092807: Jan 27 22:15:41.132 CST: TAC+: send AUTHEN/START packet ver=192 id=32850=27777
092808: Jan 27 22:15:41.936 CST: TAC+: ver=192 id=3285027777 received AUTHEN status = GETPASS
092809: Jan 27 22:15:41.936 CST: AAA/AUTHEN (3285027777): status = GETPASS
092810: Jan 27 22:15:43.340 CST: AAA/AUTHEN/CONT (3285027777): continue_login (user='dial_test')
092811: Jan 27 22:15:43.340 CST: AAA/AUTHEN (3285027777): status = GETPASS
092812: Jan 27 22:15:43.340 CST: AAA/AUTHEN (3285027777): Method=ADMIN (tacacs+)
 

 The NAS then receives the authentication FAIL message from the AAA server:


092813: Jan 27 22:15:43.340 CST: TAC+: send AUTHEN/CONT packet id=3285027777
092814: Jan 27 22:15:43.540 CST: TAC+: ver=192 id=3285027777 received AUTHEN status = FAIL
092815: Jan 27 22:15:43.540 CST: AAA/AUTHEN (3285027777): status = FAIL
 

 The session is torn down and AAA process is freed:


092816: Jan 27 22:15:45.540 CST: AAA/MEMORY: free_user (0x61D87A70) user='dial_test' ruser='' port='tty51' rem_addr='172.22.2.3' authen_type=ASCII service=LOGIN priv=1
092817: Jan 27 22:15:45.540 CST: AAA: parse name=tty51 idb type=-1 tty=-1
092818: Jan 27 22:15:45.540 CST: AAA: name=tty51 flags=0x11 type=5 shelf=0 slot
 


Step 2	 Enter the following command to assess warning and errors reported in the AAA server log file:


<CSUserver>$tail -f /var/log/csuslog
 

 AAA server log file shows that the AAA server did not find user dial_test in cache (profile caching is enabled):


Jan 27 22:15:41 coachella CiscoSecure: DEBUG - Profile USER = dial_test not found in cache.
 

 The AAA server log file also shows that AAA server did not find user in the database; next, the AAA server conducts a search for the unknown_user account:


Jan 27 22:15:41 coachella CiscoSecure: WARNING - User dial_test not found, using unknown_user
 

 AAA server finally again reports user not found after exhausting its search:


Jan 27 22:15:41 coachella CiscoSecure: DEBUG - Password:
Jan 27 22:15:43 coachella CiscoSecure: DEBUG - AUTHENTICATION CONTINUE request (c3cd8bc1)
Jan 27 22:15:43 coachella CiscoSecure: DEBUG - Authentication - User not found;
[NAS = 172.22.63.1, Port = tty51, User = dial_test, Service = 1]
 


Step 3	 Enter the following command to view a user profile in the database:


<CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u dial_test
Error: Unable to find profile
RC = 3
 


Step 4	 If the user does not exist in the database (but should), create a new user, or provide feedback if password or login were entered incorrectly by the user.





 



 6.4.4 Isolating Missing PPP Service Definition (TACACS+ Dial-Based Server Authorization)


 This scenario focuses on a server-authorization failure for a dial-based connection and provides a statement of a symptom, suggests a specific problem, and summarizes diagnostic steps. Diagnostics include output from relevant debug commands and other troubleshooting tools. See Table 6-9 for additional related problems.



Symptom   Multiple users cannot start PPP. See Table 6-9.



Step 1	 Gather general debug command information from the NAS. The following output is from a debug aaa authentication command executed on a NAS. The following output fragment shows the PPP service authorization request being initiated for user dial_tac; then, being denied by the AAA server:


111802: Feb  3 20:48:53.015 CST: As2 AAA/AUTHOR/LCP (153050196): send AV service=ppp
111803: Feb  3 20:48:53.015 CST: As2 AAA/AUTHOR/LCP (153050196): send AV protocol=lcp
111804: Feb  3 20:48:53.015 CST: As2 AAA/AUTHOR/LCP (153050196): found list "default"
111805: Feb  3 20:48:53.015 CST: As2 AAA/AUTHOR/LCP (153050196): Method=tacacs+(tacacs+)
111806: Feb  3 20:48:53.015 CST: AAA/AUTHOR/TAC+: (153050196): user=dial_tac
111807: Feb  3 20:48:53.015 CST: AAA/AUTHOR/TAC+: (153050196): send AV service=ppp
111808: Feb  3 20:48:53.015 CST: AAA/AUTHOR/TAC+: (153050196): send AV protocol=lcp
111809: Feb  3 20:48:53.219 CST: As2 AAA/AUTHOR (153050196): Post authorization status = FAIL
111810: Feb  3 20:48:53.219 CST: As2 AAA/AUTHOR/LCP: Denied
 


Step 2	 Enter the following command to assess warning and errors reported in the AAA server log file:


<CSUserver>$tail -f /var/log/csuslog
 

 AAA server log file shows that the AAA server successfully authenticated the user, but that the PPP service request was denied due to an authorization failure:


Feb  3 20:48:58 coachella CiscoSecure: DEBUG - Authentication - LOGIN successful; [NAS = 172.22.63.1, Port = Async2, User = dial_tac, Priv = 1]
Feb  3 20:48:58 coachella CiscoSecure: DEBUG - AUTHORIZATION request (468d69de)
Feb  3 20:48:58 coachella CiscoSecure: DEBUG - Authorization - Failed service; [
NAS = 172.22.63.1, user = dial_tac, port = Async2, input: service=ppp protocol=lcp output: ]
 


Step 3	 Add service=ppp and related AVPs protocol=ip and protocol=lcp.





 



 6.4.5 Isolating Defined AVPs not Being Assigned (TACACS+ Dial-Based Server Authorization)


 This scenario focuses on a server-authorization failure for a dial-based connection and provides a statement of a symptom, suggests a specific problem, and summarizes diagnostic steps. Diagnostics include output from relevant debug commands and other troubleshooting tools. See Table 6-10 for additional related problems.



Symptom   Network authorization fails. See Table 6-10.



Step 1	 Review the group profile. In this case, the group profile shows inacl=110 is assigned to the aaa_test_group profile:


    <CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -g aaa_test_group
Group Profile Information
group = aaa_test_group{
profile_id = 64
profile_cycle = 7
service=ppp {
protocol=ip {
inacl=110
}
protocol=lcp {
}
}
 
}


Step 2	 Gather general debug command information from the NAS. The following output is from a debug aaa authentication command executed on a NAS. The following output fragment shows that no AAA authorization for service=net taking place.


112037: Feb  3 21:18:04.994 CST: AAA/MEMORY: create_user (0x61DF0AE8) user='dial_tac' ruser='' port='Async5' rem_addr='async/81560' authen_type=PAP service=PPP priv=1
 


Step 3	 Enter the following command to assess warning and errors reported in the AAA server log file:


<CSUserver>$tail -f /var/log/csuslog
 

 The following log file fragment confirms that access is permitted with no AAA authentication.


Feb  3 21:18:05 coachella CiscoSecure: DEBUG - Authentication - LOGIN successful; [NAS = 172.22.63.1, Port = Async5, User = dial_tac, Priv = 1]
Feb  3 21:18:05 coachella CiscoSecure: INFO - Profile: user = dial_tac {
Feb  3 21:18:05 coachella       set server current-failed-logins = 0
Feb  3 21:18:05 coachella profile_cycle = 12
Feb  3 21:18:05 coachella }
 


Step 4	 Add aaa authorization network default group tacacs+ global command to the NAS configuration.





 



 6.4.6 Isolating Missing Shell Service Definition (TACACS+ Dial-Based Server Authorization)


 This scenario focuses on a server-authorization failure for a dial-based connection and provides a statement of a symptom, suggests a specific problem, and summarizes diagnostic steps. Diagnostics include output from relevant debug commands and other troubleshooting tools. See Table 6-16 for additional related problems.



Symptom   No EXEC shell (terminal window after dial). See Table 6-16.



Step 1	 Gather general debug command information from the NAS. The following output is from a debug aaa authentication command executed on a NAS. The following output fragment shows the request sent to AAA server to start service=shell:


092730: Jan 27 21:57:41.355 CST: tty52 AAA/AUTHOR/EXEC (3818889333): Port='tty52' list='INSIDE' service=EXEC
092738: Jan 27 21:57:41.355 CST: tty52 AAA/AUTHOR/EXEC (3818889333): Method=ADMIN (tacacs+)
092739: Jan 27 21:57:41.355 CST: AAA/AUTHOR/TAC+: (3818889333): user=dial_tac
092740: Jan 27 21:57:41.355 CST: AAA/AUTHOR/TAC+: (3818889333): send AV service=shell
 

 The following output fragments illustrate notification of the failure from AAA server for service=shell:


092741: Jan 27 21:57:41.355 CST: AAA/AUTHOR/TAC+: (3818889333): send AV cmd*
092742: Jan 27 21:57:41.559 CST: AAA/AUTHOR (3818889333): Post authorization status = FAIL
 

 The following fragment illustrates the Authorization FAILED message being detected by the debug aaa authorization process:


092743: Jan 27 21:57:41.559 CST: AAA/AUTHOR/EXEC: Authorization FAILED
092744: Jan 27 21:57:43.559 CST: AAA/MEMORY: free_user (0x61D87A70) user='dial_tac' ruser='' port='tty52' rem_addr='172.22.2.3' authen_type=ASCII service=LOGIN priv=1
 


Step 2	 Enter the following command to assess warning and errors reported in the AAA server log file:


<CSUserver>$tail -f /var/log/csuslog
 

 In this case, the authentication succeeds for user dial_tac, as illustrated in the following csuslog file fragment:


Jan 27 21:57:40 coachella CiscoSecure: DEBUG - Authentication - LOGIN successful; [NAS = 172.22.63.1, Port = tty52, User = dial_tac, Priv = 1]
 

 However, the csuslog file also shows that the authorization failed service for user dial_tac because the service=shell AVP is not assigned:


Jan 27 21:57:40 coachella CiscoSecure: DEBUG -
Jan 27 21:57:41 coachella CiscoSecure: DEBUG - AUTHORIZATION request (e39fa075)
Jan 27 21:57:41 coachella CiscoSecure: DEBUG - Authorization - Failed service; [NAS = 172.22.63.1, user = dial_tac, port = tty52, input: service=shell cmd* output: ]
 


Step 3	 Enter the following command to review the user profile. This profile shows that the AVP service=shell is not assigned to user dial_tac:


<CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u dial_tac
User Profile Information
user = dial_tac{
profile_id = 63
profile_cycle = 4
member = aaa_test_group
password = des "********"
password = pap "********"
}


Step 4	 Assign service=shell AVP.





 



 6.4.7 Isolating Incorrect PPP Reply Attributes (RADIUS Dial-Based Server Authorization)


 This scenarios focuses on a server-authorization failure for a dial-based connection using the RADIUS protocol and provides a statement of a symptom, suggests a specific problem, and summarizes diagnostic steps. Diagnostics include output from relevant debug commands and other troubleshooting tools. See Table 6-9 for additional related problems.



Symptom   PPP session is not established. See Table 6-9.



Step 1	 Gather general debug command information from the NAS. The following output is from a debug aaa authentication command executed on a NAS. The following fragment illustrates the Authorization FAILED message being detected by the debug aaa authorization process:


*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
 


Step 2	 Enter the tail command to assess warning and errors reported in the AAA server log file:


<CSUserver>$tail -f /var/log/csuslog
 

 In this case, the authorization fails for user rad_dial, as illustrated in the following csuslog file fragment:


Apr  6 15:14:03 sleddog CiscoSecure: INFO - RADIUS: Servicing requests from NAS (172.23.84.35), sending host <172.23.84.35>
 

 However, the csuslog file also shows that the authorization failed service for user dial_tac because the service=shell AVP is not assigned:


Jan 27 21:57:40 coachella CiscoSecure: DEBUG -
Jan 27 21:57:41 coachella CiscoSecure: DEBUG - AUTHORIZATION request (e39fa075)
Jan 27 21:57:41 coachella CiscoSecure: DEBUG - Authorization - Failed service; [NAS = 172.22.63.1, user = dial_tac, port = tty52, input: service=shell cmd* output: ]
 


Step 3	 Enter the following command to view a user profile in the database:


<CSUserver>$/opt/ciscosecure/CLI/ViewProfile -p 9900 -u rad_dial
 
User Profile Information
user = rad_dial{
profile_id = 23
set server current-failed-logins = 0
profile_cycle = 4
password = pap "********"
radius=Cisco {
reply_attributes= {
7=1
9,1="ip:inacl=110"
}
}
 
}       






Note In this profile, the missing reply_attribute is 6=2.





Step 4	 Add the following RADIUS AVP: Frame-Protocol=ppp (entered as 6=2 in AddProfile command input).





 



 





hometocprevnextglossaryfeedbacksearchhelp


Posted: Thu Jun  8 20:17:45 PDT 2000

Copyright 1989 - 2000©Cisco Systems Inc.