170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Cisco Systems, Inc. Corporate Headquarters Tel: 800 553-NETS (6387) 408 526-4000 Fax: 408 526-4100 Cisco AAA Implementation Case Study Internetworking Solutions Guide May 2000 Text Part Number: OL-0397-01
188
Embed
Cisco AAA Implementation Case Study - · PDF fileCisco AAA Implementation Case Study OL-0397-01 1.8.2 Authorization ... A.3 NAS AAA Command ... Authentication and Authorization Session
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Cisco AAA Implementation Case StudyInternetworking Solutions GuideMay 2000
170 West Tasman DriveSan Jose, CA 95134-1706USAhttp://www.cisco.com
Cisco Systems, Inc.Corporate Headquarters
Tel:800 553-NETS (6387)408 526-4000
Fax: 408 526-4100
Text Part Number: OL-0397-01
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Access Registrar, AccessPath, Any to Any, AtmDirector, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, the Cisco logo, Cisco Certified Internetwork Expert logo, CiscoLink, the Cisco Management Connection logo, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Capital, the Cisco Systems Capital logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, the Cisco Technologies logo, ConnectWay, Fast Step, FireRunner, Follow Me Browsing, FormShare, GigaStack, IGX, Intelligence in the Optical Core, Internet Quotient, IP/VC, Kernel Proxy, MGX, Natural Network Viewer, NetSonar, Network Registrar, the Networkers logo, Packet, PIX, Point and Click Internetworking, Policy Builder, Precept, RateMUX, ScriptShare, Secure Script, ServiceWay, Shop with Me, SlideCast, SMARTnet, SVX, The Cell, TrafficDirector, TransPath, ViewRunner, Virtual Loop Carrier System, Virtual Voice Line, VlanDirector, Voice LAN, Wavelength Router, Workgroup Director, and Workgroup Stack are trademarks; Changing the Way We Work, Live, Play, and Learn, Empowering the Internet Generation, The Internet Economy, and The New Internet Economy are service marks; and Aironet, ASIST, BPX, Catalyst, Cisco, Cisco IOS, the Cisco IOS logo, Cisco Systems, the Cisco Systems logo, the Cisco Systems Cisco Press logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastLink, FastPAD, FastSwitch, GeoTel, IOS, IP/TV, IPX, LightStream, LightSwitch, MICA, NetRanger, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any of its resellers. (0004R)
Table 6-33 Router User Receives Error Message Stating “This Line Not Allowed to Run PPP and is Disconnected” 6-28
Table 6-34 Router User Unable to Initiate Shell Session with Router 6-28
Table 6-35 AVPs Not Working on Console Port 6-28
Table A-1 Cisco IOS Commands Required to Set AAA for a Router A-13
Table A-2 Cisco IOS Commands Used to Set AAA with PPP for NAS (RADIUS and TACACS+) A-14
xCisco AAA Implementation Case Study
OL-0397-01
Preface
This case study describes various Cisco-based security and accounting capabilities for monitoring and managing access within a large-scale dial environment.
PurposeThis Internetworking Solutions Guide (ISG) case study provides examples intended to be models for building an effective, Cisco AAA-based security environment for dial-based and router environments. In following the procedures and recommendations provided in this document, readers should be able to:
• Understand the working relationship among various Cisco AAA components, including NASs, AAA servers, and the AAA database.
• Configure and verify operation for these AAA components.
• Troubleshoot typical problems found in AAA environments.
AudienceThe audience for this document consists of network engineers supporting large-scale dial networks. The audience is expected to have a basic understanding of Cisco IOS software, and a working knowledge of both the UNIX operating system and CiscoSecure for UNIX user interface.
ScopeThis case study provides:
• Complete network device configurations and specific fragments to support implementation task descriptions.
• Example diagnostic output showing verification of correct configuration.
• Troubleshooting output supporting problem scenarios show problem configurations and other AAA environment failures.
• A foundation from which effective AAA-based security solutions can be tailored to specific network requirements.
The information provided here does not include advanced tuning tips—nor does it provide a primer for the uninitiated novice. In addition, site planning and preparation are beyond the scope of this case study.
xiCisco AAA Implementation Case Study
PrefaceRelated Documentation and Sites
Related Documentation and SitesThe following URLs provide the essentials for preparing to install Cisco Secure for UNIX and NT:
Software Used in This Case StudyThe features and capabilities described in this case require these software versions:
• Cisco IOS 12.0(7)T
• OS Solaris 2.5(1)
• CiscoSecure for UNIX 2.3(3)
• Oracle DB Server 7.3(4)
• Oracle DB Client 7.3(4)
• SQL*Plus: Release 3.3.4.0.1
To identify other software versions that might apply, please contact your Cisco customer service representative.
Hardware Used in This Case StudyThis case is built on a production environment consisting of a single authentication, authorization, and accounting (AAA) server, an Oracle-based AAA database, a Cisco network access server (NAS), and a router. The diagnostic captures and system configurations provided in this case study were derived from the following systems:
• Cisco AS5300 or Cisco AS5800 network access server (NAS)
• Cisco 7206 VXR router
• Sun Microsystems server (UltraSPARC Enterprise 2 Model)
– Two 200 MHz processors
– One GB RAM
– One internal 4.2 GB disk drive
– CD-ROM drive
The system used as a platform for CiscoSecure ACS for UNIX 2.3 must meet with the minimum system specifications described in the following URL:
Cisco Connection OnlineCisco Connection Online (CCO) is the primary, real-time support channel for Cisco Systems. Maintenance customers and partners can self-register on CCO to obtain additional information and services.
Convention Description
italic File names, paths to files, user names, and groups names used in descriptions. Example: /var/log/csuslog
< > Angle brackets show nonprinting characters, such as passwords.
! An exclamation point at the beginning of a line indicates a comment line. (Exclamation points are also displayed by the Cisco IOS software for certain processes.)
[ ] Square brackets show default responses to system prompts.
Convention Description
bold Command or keyword that you must enter. This format is used for commands, paths to files, and file names when used within an example illustrating required input.
italic Argument for which you supply a value.
[x] Optional keyword or argument that you enter.
{x | y | z} Required keyword or argument that you must enter.
[x {y | z}] Optional keyword or argument that you enter with a required keyword or argument.
string Set of characters that you enter. Do not use quotation marks around the character string, or the string will include the quotation marks.
screen Information that appears on the screen.
Important line of text in an example.
^ or Ctrl Control key—for example, ^D means press the Control and the D keys simultaneously.
< > Nonprinting characters, such as passwords.
! Comment line at the beginning of a line of code.
xiiiCisco AAA Implementation Case Study
PrefaceDocumentation CD-ROM
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to customers and business partners of Cisco Systems. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
You can access CCO in the following ways:
• http://www.cisco.com
• http://www-europe.cisco.com
• http://www-china.cisco.com
• Telnet: cco.cisco.com
• Modem: From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.
For a copy of the CCO Frequently Asked Questions (FAQ), contact [email protected]. For additional information, contact [email protected].
Note If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact the Cisco Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or [email protected]. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or [email protected].
Documentation CD-ROMCisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly; therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
Providing Documentation FeedbackIf you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can also submit feedback on Cisco documentation as follows:
xivCisco AAA Implementation Case Study
PrefaceAcknowledgements
• Mail in the Cisco Reader Comment Card located at the front of this book
AcknowledgementsThis ISG case study was created as a collaborative effort. The following team members participated in the creation of this document: Joellen Amato, Dave Anderson, Robert “Bob” Brown, Alan Dowling, Dianne Dunlap, Paul Hafeman, Anthony Hall, Kim Lew, Robert Lewis, Dave Leyland, Brian Murphy, Dang Nguyen, Nilesh Panicker, Anjali Puri, Robert Sargent, David Sims, Tim Stevenson, Kris Thompson, Craig Tobias, and Syed Atif Ullah.
xvCisco AAA Implementation Case Study
PrefaceAcknowledgements
xviCisco AAA Implementation Case Study
Cis
C H A P T E R 1
Cisco AAA Case Study Overview
This chapter summarizes the technology behind AAA security solutions, outlines typical network definitions and network assumptions adopted for this case study, and lists tasks associated with implementing, verifying, and troubleshooting the AAA environment presented. Specific sections provided here are:
• 1.1 AAA Technology Summary
• 1.2 TACACS+ Overview
• 1.3 RADIUS Overview
• 1.4 Comparison of TACACS+ and RADIUS
• 1.5 Differences in Implementing Local and Server AAA
1.1 AAA Technology SummaryDial access presents a challenge to network managers entrusted with network security. This case study illustrates essential steps in planning and implementing authentication, authorization, and accounting (AAA) technologies based on Cisco product capabilities.
For the purposes of this case study, the following generic definitions apply:
• Authentication: The process of validating the claimed identity of an end user or a device, such as a host, server, switch, router, and so on.
• Authorization: The act of granting access rights to a user, groups of users, system, or a process.
• Accounting: The methods to establish who, or what, performed a certain action, such as tracking user connection and logging system users.
Figure 1-1 illustrates a generalized view of a Cisco-based AAA environment, featuring a network access server (NAS) and AAA server. This basic arrangement forms the foundation for this case study.
1-1co AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.2 TACACS+ Overview
In the context of the Cisco-based AAA environment addressed here, the key operational elements are network access servers (NASs), routers, and CiscoSecure Access Control Server for UNIX servers (referred to in this document as AAA servers). Depending on the conventions and requirements of your particular design, you can select a security environment which utilizes Terminal Access Controller Access Control System Plus (TACACS+) or Remote Authentication Dial-in User Service (RADIUS). This case study addresses implementation of both environments.
1.1.1 AAA RFC ReferencesRequests for Comments (RFCs) play a crucial role in defining the behavior of devices in complex networking environments. The following RFCs are useful references for TACACS+ and RADIUS:
• TACACS+ separates AAA into three distinct functions (Authentication, Authorization and Accounting).
• TACACS+ supports router command authorization integration with advanced authentication mechanisms, such as Data Encryption Standard (DES) and One-Time Password (OTP) key.
• TACACS+ supports 16 different privilege levels (0-15).
Internet
3508
9
Clients Modems
Network elementmanagement server (NTP, Syslog, SNMP)
AAAserver
Internetfirewall
Defaultgateway
Cisco AS5x00with integrated
modems
PSTNPRI linesAnalog lines
DNSserver
Oracle dB server
IP intranet
1-2Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.3 RADIUS Overview
• TACACS+ permits the control of services, such as Point-to-Point Protocol (PPP), shell, standard log in, enable, AppleTalk Remote Access (ARA) protocol, Novell Asynchronous Services Interface (NASI), remote command (RCMD), and firewall proxy.
• TACACS+ permits the blocking of services to a specific port, such as a TTY or VTY interface on a router.
The most common services supported by TACACS+ are PPP for IP and router EXEC shell access using console or VTY ports. EXEC shell allows users to connect to router shells and select services, such as PPP, Telnet, TN3270, or manage the router itself.
Many TACACS+ servers are available on the market today; however, the AAA server is designed specifically to be scalable and compatible with Cisco's broad line of routers, access servers, and switches. Hence, this case utilizes the Cisco AAA server as the TACACS+ server of choice.
When configured correctly, the AAA server validates AAA and responds to requests from routers and access servers with a pass or fail signal. The AAA server contains an internal database sized to 5000 users; therefore, an external Oracle database is used in our case study for user account attributes and billing information.
The AAA server acts as a proxy server by using TACACS+ to authenticate, authorize, and account for access to Cisco routers and network access servers.
1.3 RADIUS OverviewThe RADIUS protocol was developed by Livingston Enterprises, Inc., as an access server authentication and accounting protocol. The RADIUS specification (RFC 2138) is a proposed standard protocol and RADIUS accounting standard (RFC 2139) is informational.
Although TACACS+ is considered to be more versatile, RADIUS is the AAA protocol of choice for enterprise ISPs because it uses fewer CPU cycles and is less memory intensive.
Communication between a network access server (NAS) and a RADIUS server is based on the User Datagram Protocol (UDP). Generally, the RADIUS protocol is considered a connectionless service. Issues related to server availability, retransmission, and timeouts are handled by the RADIUS-enabled devices rather than the transmission protocol.
RADIUS is a client/server protocol. The RADIUS client is typically a NAS and the RADIUS server is usually a daemon process running on a UNIX or Windows NT machine. The client passes user information to designated RADIUS servers and acts on the response that is returned. RADIUS servers receive user connection requests, authenticate the user, and then return the configuration information necessary for the client to deliver services to the user. A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers.
1-3Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.4 Comparison of TACACS+ and RADIUS
1.4 Comparison of TACACS+ and RADIUSTable 1-1 summarizes the differences between RADIUS and TACACS+.
1.4.1 UDP and TCPRADIUS uses UDP while TACACS+ uses TCP. TCP offers several advantages over UDP. TCP offers a connection-oriented transport, while UDP offers best effort delivery. RADIUS requires additional programmable variables, such as retransmit attempts and time-outs to compensate for best-effort transport, and it lacks the level of built-in support that reliable transport offers:
• Using TCP provides a separate acknowledgment that a request has been received, within (approximately) a network RTT, regardless of bandwidth. (TCP ACK).
• TCP provides immediate indication of a crashed (or not running) server (RST packets). You can determine when a server has crashed and come back up if you use long-lived TCP connections. UDP cannot tell the difference between a server that is out-of-service, slow, or non-existent server.
• By using TCP keepalives, you can detect server crashes out-of-band with actual requests. Connections to multiple servers can be maintained simultaneously, and you only need to send messages to the servers that are known to be up and running.
• TCP is more scalable than UDP.
1.4.2 Packet Encryption RADIUS encrypts only the password in the access-request packet from the client to the server. The remainder of the packet is in the clear. Other information, such as username, authorized services, and accounting, can be captured by a third party.
RADIUS can use encrypted passwords by using the UNIX /etc/password file; however, this process is slow because in involves a linear search of the file.
Table 1-1 Comparison of RADIUS and TACACS+
RADIUS TACACS+
RADIUS uses UDP. TACACS+ uses TCP.
RADIUS encrypts only the password in the access-request packet; less secure.
TACACS+ encrypts the entire body of the packet; more secure.
RADIUS combines authentication and authorization.
TACACS+ uses the AAA architecture, which separates authentication, authorization, and accounting.
Industry standard (created by Livingston). Cisco Proprietary.
RADIUS does not support ARA access, Net BIOS Frame Protocol Control protocol, NASI, and X.25 PAD connections.
TACACS+ offers multiprotocol support.
RADIUS does not allow users to control which commands can be executed on a router.
TACACS+ provides two ways to control the authorization of router commands: on a per-user or per-group basis.
1-4Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.4 Comparison of TACACS+ and RADIUS
TACACS+ encrypts the entire body of the packet but leaves a standard TACACS+ header. Within the header is a field that indicates whether the body is encrypted or not. For debugging purposes, it is useful to have the body of the packets in the clear. However, normal operation fully encrypts the body of the packet for more secure communications.
1.4.3 Authentication and AuthorizationRADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contain authorization information, making it difficult to decouple authentication and authorization.
TACACS+ uses the AAA architecture, which separates authentication, authorization, and accounting. This architecture allows separate authentication solutions that can still use TACACS+ for authorization and accounting. For example, with TACACS+, it is possible to use Kerberos authentication and TACACS+ authorization and accounting. After a NAS passes authentication on a Kerberos server, it requests authorization information from a TACACS+ server without having to re-authenticate the NAS by using the TACACS+ authentication mechanism. The NAS informs the TACACS+ server that it has successfully passed authentication on a Kerberos server, and the server then provides authorization information.
During a session, if additional authorization checking is needed, the access server checks with a TACACS+ server to determine if the user is granted permission to use a particular command. This provides greater control, compared to RADIUS, over the commands that can be executed on the access server while decoupling the authorization process from the authentication mechanism.
1.4.4 Multiprotocol SupportRADIUS does not support the following protocols (which are supported by TACACS+):
• AppleTalk Remote Access (ARA) protocol
• Net BIOS Frame Protocol Control protocol
• Novell Asynchronous Services Interface (NASI)
• X.25 PAD connection
1.4.5 Router ManagementRADIUS does not allow users to control which commands can be executed on a router and which cannot; therefore, when compared with TACACS+, RADIUS is not as useful for router management and is not as flexible for terminal services.
TACACS+ provides two ways to control the authorization of router commands on a per-user or per-group basis. The first way is to assign privilege levels to commands and have the router verify with the TACACS+ server whether or not the user is authorized at the specified privilege level. The second way is to explicitly specify in the TACACS+ server, on a per-user or per-group basis, the commands that are allowed.
1-5Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.5 Differences in Implementing Local and Server AAA
1.4.6 Interoperability The RADIUS standard does not guarantee interoperability. Although several vendors implement RADIUS clients, this does not ensure they are interoperable. There are approximately 45 standard RADIUS ATTRIBUTES. Using standard ATTRIBUTES improves the likelihood of interoperability. Using proprietary extensions reduces interoperability.
1.4.7 Attribute-Value Pairs (AVPs)Throughout this case study, implementation tasks and diagnostic procedures refer to attribute-value pairs (AVPs). Each AVP consists of a type identifier associated with one or more assignable values. AVPs specified in user and group profiles define the authentication and authorization characteristics for their respective users and groups. TACACS+ and RADIUS implement an array of AVPs, each with separate type definitions and characteristics. Table 1-2 and Table 1-3 illustrate several typical AVPs.
1.5 Differences in Implementing Local and Server AAAAAA requirements differ between local-based and server-based environments. Throughout this case study, procedures and examples refer to scenarios based on this important distinction.
In local-based AAA access, users are permitted or denied access based on local AAA IOS account configuration. For the purposes of this case study, local-based AAA access features these attributes:
Table 1-2 Examples of RADIUS AVPs
Attribute Type of Value
User-Name String
Password String
CHAP-Password String
Client-Id IP address
Login-Host IP address
Login-Service Integer
Login-TCP-Port Integer
Table 1-3 Examples of TACACS+ AVPs
Attribute Type of Value
Inacl Integer
Addr-pool String
Addr IP address
Idletime Integer
protocol Keyword
timeout Integer
Outacl Integer
1-6Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.5 Differences in Implementing Local and Server AAA
• User accounts are stored in router or NAS configurations.
• AVPs only are supported from EXEC shell terminal access.
• Limited set of AVPs are supported.
• AAA negotiation is performed internally by the Cisco IOS and is not protocol specific.
Figure 1-2 illustrates three local-based connectivity situations to consider:
• Local-based console access
• Local-based virtual terminal type (VTY) connections
• Local-based dial access
Figure 1-2 Local-Based Access Options
In server-based AAA access, users and groups are permitted or denied access based on AAA negotiations between s router or NAS and the AAA server. See the following attributes of server-based AAA access features:
• User or group profiles and accounting records stored in an internal or external database
• AVPs supported on both standard and EXEC shell-initiated PPP sessions
• Wide array of AVPs supported, including vendor-specific (non-Cisco) AVPs
Figure 1-3 illustrates the three server-based connectivity situations:
• Server-based console access
• Server-based VTY connections
• Server-based dial access
IP
IP
3134
8
Local-basedconsole access
IP
Local-basedVTY access (Telnet)
Local-baseddial access
PSTNModem
1-7Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.6 Scenario Description
Figure 1-3 Server-Based Access Options
Each connectivity scenario illustrated in Figure 1-2 and Figure 1-3 involves situation-specific requirements. As a result, each scenario also contains situation-specific implementation and troubleshooting considerations. The diagnostic chapters that follow present a series of implementation steps (configuring, verifying, and testing) symptoms, problems, and suggested diagnostic processes that reflect both these differences and similarities.
1.6 Scenario DescriptionThe baseline network environment for a hypothetical access network scenario is used as a foundation for assessing the application of various security and management features available from Cisco. Figure 1-1 (presented in “1.1 AAA Technology Summary”) illustrates the underlying network environment and relationship between AAA components. The high-level AAA objectives:
• Enable secure dialup service to access an intranet and the Internet by using the public switched telephone network (PSTN).
• Build a manageable, redundant, and secure access strategy that supports large dialup access implementations.
• Provide versatile means of controlling administrative access to routers.
IP
AAA server
IP
AAA server
3134
7
Server-basedconsole access
IP
AAA server
Server-basedVTY access (Telnet)
Server-baseddial access
PSTNModem
1-8Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.7 Planning Your Network
• Account for configuration changes in routers.
1.7 Planning Your NetworkA network design engineer meets with each company to complete the following tasks:
• Complete a needs assessment dial questionnaire.
• Create a user-network service definition.
• Recommend a network implementation and operation strategy.
The following tables present two checklists that were completed for this case study. Table 1-4 focuses on general networking issues. Table 1-5 focuses on AAA implementation issues. Both checklists apply to a hypothetical network referred to in this case as Access Network.
Table 1-4 General Service Definition Checklist
General Access Network Checklist Questions Access Network Policy
What media do you want to use to provide dialup service?
Plain old telephone service (POTS) analog modems
ISDN
How many dial-in users does the new equipment need to support over the next 3 months, 1 year, and 5 years?
3 months: 2000 users
1 Year: 5,000 users
5 Years: 10,000 users
What kind of remote nodes do you want to support?
Modems, terminal adapters, ISDN modems
When users connect to modems, what will they be allowed to do?
Support EXEC shell sessions (async terminal service)
Support PPP sessions
Will you allow users to change their own passwords? If yes, how?
Yes
EXEC shell (character-mode session)
What kind of dialup operating systems do you want to support?
Windows, UNIX, Macintosh
Do you want to support remote routers? Asynch DDR or multiple B-channel access
Do you want to use an external authentication database such as Windows NT or Novel NDS?
Yes, Oracle
Do you want to support per user protocol and attribute definitions?
Yes
Do you want to support dial out? No
Do you want to support PPP timeouts? No
Do you want to work with an existing accounting system?
Yes
Do you have an existing network element server? Yes
1-9Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.8 Network Service Definitions
1.8 Network Service DefinitionsBased on the checklist information provided in Table 1-4 and Table 1-5, the following service definitions (stated as policies) can be asserted for this environment.
Dialup and router shell access AAA requirements are characterized in the following sections:
• 1.8.1 Authentication Policy
• 1.8.2 Authorization Policy
• 1.8.3 Accounting Policy
1.8.1 Authentication PolicySeparate the authentication policy into two distinct sections: router administration and dialup PPP.
Policies relating to router administration involve creating support for the following two authentication elements:
• DES passwords stored in external database
• Local user if connection to AAA server is down
Policies relating to dialup PPP involve creating support for the following two authentication elements:
• Password Authentication Protocol (PAP) for dialup PPP authentication
• Challenge Handshake Authentication Protocol (CHAP) for remote ISDN devices
What AAA protocols do you plan to deploy? RADIUS and TACACS+
Where do you want the users’ passwords to be stored?
External Oracle database
Do you plan to support one-time passwords? If so, what tool do you plan to use to support this requirement?
No
Do you intend to implement database replication? No
Do you require support for token caching? No
What type of accounts currently exist? UNIX, NT
Do you plan to implement an AAA server? If so, on which product?
Yes, CiscoSecure for UNIX
What database do you plan to use? External, Oracle
1-10Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.8 Network Service Definitions
1.8.2 Authorization PolicySeparate the authorization policy into two distinct sections: router administration and dialup PPP.
Policies relating to router administration involve creating support for the following authorization elements:
• Privilege level 15 command authorization
• Three levels of router administration command control (low, medium, and high)
• Privilege level 15 assigned to local users, which is valid only if an AAA server is down
Policies relating to dialup PPP involve creating support for the following authorization elements:
• Apply autocommand ppp negotiate to all groups other than router administrators
• Access control list filtering as required
• AVP support for all dial access devices
1.8.3 Accounting PolicyAccounting records are exported from an Oracle database using SQL queries. Separate the accounting policy into two distinct sections: router administration and dialup PPP.
Policies relating to router administration involve creating support for the following accounting elements:
• Failed log in attempts
• Privilege level 15 commands
• Failed command authorization
• Start, stop, and elapsed times of sessions
• Source IP address of routers
Policies relating to dialup PPP involve creating support for the following accounting elements:
• Failed log in attempts
• Start, stop, and elapsed time of sessions
• Disconnect cause codes
• Caller ID if applicable
1-11Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.9 Security Implementation Policy Considerations
1.9 Security Implementation Policy ConsiderationsTable 1-6 present checklists summarizing the key security policy elements of this case.
What is the current security policy for passwords? PAP for dial-in PPP users
CHAP passwords for dialup routers
DES passwords for router administrators
What services will be denied? Concurrent sessions for dial-in users
EXEC shell access for dial-in PPP users
Access to specific hosts within the corporate intranetwork
Access to specific network services, such as Telnet, FTP, and rlogin
What type of mechanism will exist if AAA server is down?
Local privilege level 15 account
Authentication and authorization disabled on console port
Are local accounts allowed in routers and NASs? Yes
What accounting information is required? Username
Privilege level of clients
Session start and stop times
Elapsed time
Privilege level 15 command usage
Configuration changes
Failed log in attempts
Failed command authorizations
What type of accounting mechanism will be used? Customer written SQL query to Oracle database
Who is responsible for reviewing daily logs? Network managers
Will users be allowed concurrent sessions? Dialup PPP = No
Dialup router = Yes
Router administrator = Yes
What type of administrative access will be assigned to router administrators?
Full control assigned to senior router administrators
Basic control assigned to junior router administrators
Customized command control for mid-level router administrators
Support for Multilink? Yes
1-12Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.10 Network Equipment Selection
In addition to these considerations, security-related attributes addressed in this case include:
• Per-User Static IP Address Policy—Static IP addresses are assigned to required personnel to access specific areas within the internetwork.
• Password Authentication and Command Authorization Policy—DES password support is segregated into two elements: privilege level and command authorization. Within that context, three levels of privilege are supported in this case: low, medium, and high, with high having full control assigned. Command authorization at privilege level 15 is enforced. A local user with privilege level 15 is used in the event that the connection to the AAA server is down.
1.10 Network Equipment SelectionFigure 1-1 (presented in “1.1 AAA Technology Summary”) shows the specific devices used in the dialup access environment. Based on the requirements detailed in Table 1-4, Table 1-5, and Table 1-6, the following network entities were selected for this case study:
• Remote clients using modems to access the IP intranet and IP Internet through the public switched telephone network (PSTN).
• An AAA server.
• An password authentication server.
• An external Oracle database server acts as the repository for all user profile information.
• An element management server performs basic dial access system management by using the network time protocol (NTP), system logs (syslog), and simple network management protocol (SNMP).
• A remote AAA server performs basic user authentication.
• A default gateway forwards packets to the IP intranet and IP Internet.
1-13Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.11 Task Check List
1.11 Task Check ListTable 1-7 summarizes AAA management implementation and operation activities for the hypothetical network in this case study. This case focuses on illustrating implementation of specific AAA-related security and management options over an Access Path implementation. Refer to Cisco AS5x00 Case Study for Basic IP Modem Service for specifics regarding commissioning Cisco access servers to support modem services at the following URL:
Chapter 6, “Diagnosing and Troubleshooting AAA Operations”
6.1 Overview of Authentication and Authorization Processes
6.2 Troubleshooting AAA Implementation
• 6.2.1 Troubleshooting Methodology Overview
• 6.2.2 Cisco IOS Debug Command Summary
6.3 AAA Troubleshooting Basics
6.4 Troubleshooting Scenarios
Table 1-7 AAA Task Checklist
Task Topic
1-15Cisco AAA Implementation Case Study
Chapter 1 Cisco AAA Case Study Overview1.11 Task Check List
1-16Cisco AAA Implementation Case Study
Cis
C H A P T E R 2
Implementing the Local AAA Subsystem
This chapter focuses on local AAA implementation and describes the following topics:
• 2.1 Implementing Local Dialup Authentication
• 2.2 Implementing Local Dialup Authorization
• 2.3 Implementing Local Router Authentication
• 2.4 Implementing Local Router Authorization
Note See “1.1 AAA Technology Summary,” in Chapter 1 for brief definitions of authentication, authorization, and accounting as they relate to AAA security implementation.
Server-based authentication, authorization, and accounting issues are described in the following chapters:
• Chapter 3, “Implementing Cisco AAA Servers”
• Chapter 4, “Implementing the Server-Based AAA Subsystem”
• Chapter 6, “Diagnosing and Troubleshooting AAA Operations”
Caution The example configuration fragments used throughout this chapter include IP addresses, passwords, authentication keys, and other variables that are specific to this case study. If you use these fragments as foundations for you own configurations, be sure that your specifications apply to your environment.
2-1co AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.1 Implementing Local Dialup Authentication
2.1 Implementing Local Dialup Authentication These steps help you to establish local-based dial authentication as illustrated in Figure 2-1:
1. Configure basic dial access.
2. Verify basic dial access.
Figure 2-1 Local-Based Dial Access Environment
Step 1 Configure basic dial access.
Include the following Cisco IOS configuration commands in your configuration to construct dial access local authentication control:
aaa new-modelaaa authentication login default local aaa authentication ppp default if-needed local username diallocal password xxxxxx
interface Group-Async1 ip unnumbered Loopback0 no ip directed-broadcast encapsulation ppp ip tcp header-compression passive no logging event link-status dialer in-band dialer idle-timeout 900 async mode interactive no snmp trap link-status peer default ip address pool default no fair-queue no cdp enable ppp max-bad-auth 3 ppp authentication pap chap group-range 1 48
line 1 48 exec-timeout 48 0 autoselect during-login autoselect ppp absolute-timeout 240 script dialer cisco_default modem InOut modem autoconfigure type mica transport preferred telnet transport input all transport output pad telnet rlogin udptn
IP
3505
4
Local-baseddial access
PSTNModem
2-2Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.1 Implementing Local Dialup Authentication
Note See “A.3 NAS AAA Command Implementation Descriptions” in Appendix A, “AAA Device Configuration Listings” for notes regarding key Cisco IOS AAA commands.
Step 2 Verify basic dial access.
a. To verify user access, initiate a login process as follows:
maui-nas-01#login
User Access Verification
Username:diallocalPassword: <password>
b. To determine that local dial access authentication is operating correctly, enter the debug aaa authentication and debug ppp authentication commands.
The following debug output contains only pertinent information:
maui-nas-01#
Debugs in NAS then initiate dialup:
maui-nas-01#debug aaa authenticationAAA Authentication debugging is onmaui-nas-01#debug ppp authenticationPPP authentication debugging is onmaui-nas-01#show debugGeneral OS: AAA Authentication debugging is onPPP: PPP authentication debugging is on
2-3Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.1 Implementing Local Dialup Authentication
The following shell-initiated PPP session example shows the AAA debug output that confirms correct configuration for local authentication:
Note The method used is LOCAL.
113123: Feb 4 10:11:19.305 CST: AAA/MEMORY: create_user (0x619C4940) user='' ruser='' port='tty1' rem_addr='async/81560' authen_type=ASCII service=LOGIN priv=1113124: Feb 4 10:11:19.305 CST: AAA/AUTHEN/START (2784097690): port='tty1' list='' action=LOGIN service=LOGIN113125: Feb 4 10:11:19.305 CST: AAA/AUTHEN/START (2784097690): using "default" list113126: Feb 4 10:11:19.305 CST: AAA/AUTHEN/START (2784097690): Method=LOCAL113127: Feb 4 10:11:19.305 CST: AAA/AUTHEN (2784097690): status = GETUSER113128: Feb 4 10:11:26.305 CST: AAA/AUTHEN/CONT (2784097690): continue_login (user='(undef)')113129: Feb 4 10:11:26.305 CST: AAA/AUTHEN (2784097690): status = GETUSER113130: Feb 4 10:11:26.305 CST: AAA/AUTHEN/CONT (2784097690): Method=LOCAL113131: Feb 4 10:11:26.305 CST: AAA/AUTHEN (2784097690): status = GETPASS113132: Feb 4 10:11:28.145 CST: AAA/AUTHEN/CONT (2784097690): continue_login (user='diallocal')113133: Feb 4 10:11:28.145 CST: AAA/AUTHEN (2784097690): status = GETPASS113134: Feb 4 10:11:28.145 CST: AAA/AUTHEN/CONT (2784097690): Method=LOCAL113135: Feb 4 10:11:28.145 CST: AAA/AUTHEN (2784097690): status = PASS113136: Feb 4 10:11:32.582 CST: As1 PPP: Treating connection as a callin113137: Feb 4 10:11:32.582 CST: AAA/MEMORY: dup_user (0x61DF306C) user='dialuser' ruser='' port='tty1' rem_addr='async/81560' authen_type=ASCII service=PPP priv=1 source='AAA dup lcp_reset'113138: Feb 4 10:11:32.582 CST: As1 AAA/AUTHEN: Method=IF-NEEDED: no authentication needed. user='diallocal' port='tty1' rem_addr='async/81560'113139: Feb 4 10:11:32.582 CST: AAA/MEMORY: free_user (0x619C4940) user='dialuser' ruser='' port='tty1' rem_addr='async/81560' authen_type=ASCII service=LOGIN priv=1113140: Feb 4 10:11:33.158 CST: AAA/MEMORY: dup_user (0x6193A788) user='dialuser' ruser='' port='tty1' rem_addr='async/81560' authen_type=ASCII service=PPP priv=1 source='AAA dup lcp_reset'113141: Feb 4 10:11:33.158 CST: AAA/MEMORY: free_user (0x61DF306C) user='dialuser' ruser='' port='tty1' rem_addr='async/81560' authen_type=ASCII service=PPP priv=1113142: Feb 4 10:11:33.158 CST: As1 AAA/AUTHEN: Method=IF-NEEDED: no authentication needed. user='diallocal' port='tty1' rem_addr='async/81560'
2-4Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.2 Implementing Local Dialup Authorization
The following example of a non-shell-initiated PPP session shows AAA debug output that confirms correct configuration for local authentication:
Note The method used is LOCAL.
113151: Feb 4 10:13:27.670 CST: AAA/MEMORY: create_user (0x61DFE188) user='' ruser='' port='tty2' rem_addr='async/81560' authen_type=ASCII service=LOGIN priv=1113152: Feb 4 10:13:27.670 CST: AAA/AUTHEN/START (776784700): port='tty2' list='' action=LOGIN service=LOGIN113153: Feb 4 10:13:27.670 CST: AAA/AUTHEN/START (776784700): using "default" list113154: Feb 4 10:13:27.670 CST: AAA/AUTHEN/START (776784700): Method=LOCAL113155: Feb 4 10:13:27.670 CST: AAA/AUTHEN (776784700): status = GETUSER113156: Feb 4 10:13:27.710 CST: AAA/AUTHEN/ABORT: (776784700) because Autoselected.113157: Feb 4 10:13:27.710 CST: AAA/MEMORY: free_user (0x61DFE188) user='' ruser='' port='tty2' rem_addr='async/81560' authen_type=ASCII service=LOGIN priv=1113158: Feb 4 10:13:29.842 CST: As2 PPP: Treating connection as a callin113159: Feb 4 10:13:34.834 CST: As2 PAP: I AUTH-REQ id 1 len 18 from "diallocal"113160: Feb 4 10:13:34.834 CST: As2 PAP: Authenticating peer diallocal113161: Feb 4 10:13:34.838 CST: AAA: parse name=Async2 idb type=10 tty=2113162: Feb 4 10:13:34.838 CST: AAA: name=Async2 flags=0x11 type=4 shelf=0 slot=0 adapter=0 port=2 channel=0113163: Feb 4 10:13:34.838 CST: AAA: parse name=Serial0:3 idb type=12 tty=-1113164: Feb 4 10:13:34.838 CST: AAA: name=Serial0:3 flags=0x51 type=1 shelf=0 slot=0 adapter=0 port=0 channel=3113165: Feb 4 10:13:34.838 CST: AAA/MEMORY: create_user (0x61ABBCE4) user='dialuser' ruser='' port='Async2' rem_addr='async/81560' authen_type=PAP service=PPP priv=1113166: Feb 4 10:13:34.838 CST: AAA/AUTHEN/START (1001880850): port='Async2' list='' action=LOGIN service=PPP113167: Feb 4 10:13:34.838 CST: AAA/AUTHEN/START (1001880850): using "default" list113168: Feb 4 10:13:34.838 CST: AAA/AUTHEN (1001880850): status = UNKNOWN113169: Feb 4 10:13:34.838 CST: AAA/AUTHEN/START (1001880850): Method=LOCAL113170: Feb 4 10:13:34.838 CST: AAA/AUTHEN (1001880850): status = PASS113171: Feb 4 10:13:34.838 CST: As2 PAP: O AUTH-ACK id 1 len 5
2.2 Implementing Local Dialup AuthorizationThese processes help you to accomplish the following tasks:
1. Configure dial access configuration for local authorization on the NAS.
2. Verify and troubleshoot local authorization from NAS.
3. Verify that access list 110 is assigned.
Note Attribute-value pairs (AVPs) only are supported with EXEC shell initiated PPP sessions for local accounts. Configure dial access clients to “Bring Up a Terminal Window After Dial”.
2-5Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.2 Implementing Local Dialup Authorization
Step 1 Configure dial access configuration for local authorization on the NAS.
Include the following Cisco IOS configuration commands in your configuration to construct dial access local authorization:
aaa new-modelaaa authentication login default local aaa authentication ppp default if-needed localaaa authorization exec default local if-authenticated aaa authorization network default local if-authenticated username dialclient access-class 110 password ciscorocksusername dialclient autocommand ppp negotiate access-list 110 deny tcp any any eq telnetaccess-list 110 permit tcp any any
Note See “A.3 NAS AAA Command Implementation Descriptions” in Appendix A, “AAA Device Configuration Listings” for notes regarding key Cisco IOS AAA commands.
Step 2 Verify and troubleshoot local authorization from NAS.
To verify local dial access authorization is operating correctly, enter the debug aaa authorization command.
The following EXEC sequence illustrates that the appropriate command is enabled:
5800-NAS#show debugGeneral OS: AAA Authorization debugging is on
The following example of a shell-initiated session shows the AAA debug output that confirms correct configuration for local authorization. Some points to note about this debug output:
• Method used is LOCAL.
• Autocommand used is PPP negotiate.
• Access list used is 110.
• Authorization is successful.
The following tests illustrate operations described in “2.4 Implementing Local Router Authorization” and include relevant router output:
1. User diallocal is authorized EXEC Shell Service (Terminal Window After Dial enabled).
2. EXEC Authorization in action; access-list 110 and autocommand=ppp negototiate AVPs processed.
3. User diallocal is authorized PPP Network Service.
4. User diallocal is authorized LCP.
5. User diallocal is authorized IPCP.
The following diagnostic results are presented in the order in which they are generated during the authorization process. Specific output fragments are differentiated with brief explanatory notes to help you identify relevant information.
2-6Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.2 Implementing Local Dialup Authorization
Note The debug command output can vary depending on Cisco IOS versions.
1. User diallocal is authorized EXEC Shell Service (Terminal Window After Dial enabled).
NAS debug output:
07:10:52: As10 AAA/AUTHOR/EXEC (693880654): Port='tty10' list='' service=EXEC07:10:52: AAA/AUTHOR/EXEC: As10 (693880654) user='diallocal'07:10:52: As10 AAA/AUTHOR/EXEC (693880654): send AV service=shell07:10:52: As10 AAA/AUTHOR/EXEC (693880654): send AV cmd*07:10:52: As10 AAA/AUTHOR/EXEC (693880654): found list "default"07:10:52: As10 AAA/AUTHOR/EXEC (693880654): Method=LOCAL07:10:52: As10 AAA/AUTHOR (693880654): Post authorization status = PASS_ADD
2. EXEC Authorization in action; access-list 110 and autocommand=ppp negototiate AVPs processed.
NAS debug output:
07:10:52: AAA/AUTHOR/EXEC: Processing AV service=shell07:10:52: AAA/AUTHOR/EXEC: Processing AV cmd*07:10:52: AAA/AUTHOR/EXEC: Processing AV autocmd=ppp07:10:52: AAA/AUTHOR/EXEC: Processing AV acl=11007:10:52: AAA/AUTHOR/EXEC: Authorization successful
3. User diallocal is authorized PPP Network Service.
NAS debug output:
07:10:52: As10 AAA/AUTHOR/PPP (2856468577): Port='tty10' list='' service=NET07:10:52: AAA/AUTHOR/PPP: As10 (2856468577) user='diallocal'07:10:52: As10 AAA/AUTHOR/PPP (2856468577): send AV service=ppp07:10:52: As10 AAA/AUTHOR/PPP (2856468577): send AV protocol=ip07:10:52: As10 AAA/AUTHOR/PPP (2856468577): send AV addr-pool*default07:10:52: As10 AAA/AUTHOR/PPP (2856468577): found list "default"07:10:52: As10 AAA/AUTHOR/PPP (2856468577): Method=LOCAL07:10:52: As10 AAA/AUTHOR (2856468577): Post authorization status = PASS_REPL
4. User diallocal is authorized LCP.
NAS debug output:
07:10:52: AAA/AUTHOR/Async10: PPP: Processing AV service=ppp07:10:52: AAA/AUTHOR/Async10: PPP: Processing AV protocol=ip07:10:52: AAA/AUTHOR/Async10: PPP: Processing AV addr-pool*default07:10:54: AAA/MEMORY: free_user (0x61851148) user='diallocal' ruser='' port='tty10' rem_addr='65004/65301' authen_type=ASCII service=LOGIN priv=107:10:56: AAA/MEMORY: free_user (0x61532710) user='diallocal' ruser='' port='tty10' rem_addr='65004/65301' authen_type=ASCII service=PPP priv=107:10:56: As10 AAA/AUTHOR/FSM: (0): LCP succeeds trivially07:10:58: As10 AAA/AUTHOR/LCP: Authorize LCP07:10:58: As10 AAA/AUTHOR/LCP (3185006257): Port='tty10' list='' service=NET07:10:58: AAA/AUTHOR/LCP: As10 (3185006257) user='diallocal'07:10:58: As10 AAA/AUTHOR/LCP (3185006257): send AV service=ppp07:10:58: As10 AAA/AUTHOR/LCP (3185006257): send AV protocol=lcp07:10:58: As10 AAA/AUTHOR/LCP (3185006257): found list "default"07:10:58: As10 AAA/AUTHOR/LCP (3185006257): Method=LOCAL07:10:58: As10 AAA/AUTHOR (3185006257): Post authorization status = PASS_REPL
2-7Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.3 Implementing Local Router Authentication
5. User diallocal is authorized IPCP.
NAS debug output:
07:10:58: As10 AAA/AUTHOR/LCP: Processing AV service=ppp07:10:58: As10 AAA/AUTHOR/LCP: Processing AV protocol=lcp07:10:58: As10 AAA/AUTHOR/FSM: (0): Can we start IPCP?07:10:58: As10 AAA/AUTHOR/FSM (321297806): Port='tty10' list='' service=NET07:10:58: AAA/AUTHOR/FSM: As10 (321297806) user='diallocal'07:10:58: As10 AAA/AUTHOR/FSM (321297806): send AV service=ppp07:10:58: As10 AAA/AUTHOR/FSM (321297806): send AV protocol=ip07:10:58: As10 AAA/AUTHOR/FSM (321297806): found list "default"07:10:58: As10 AAA/AUTHOR/FSM (321297806): Method=LOCAL
07:10:58: As10 AAA/AUTHOR (321297806): Post authorization status = PASS_REPL07:10:58: As10 AAA/AUTHOR/FSM: We can start IPCP
Step 3 Verify that access list 110 is assigned.
To verify that access list 110 is being used to control access, enter the show line command as follows:
maui-nas-03#show line 10 Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns IntA 10 TTY - inout - 110 - 1 0 0/0 -
Note Access lists can be defined as either input or output access lists. As configured and applied in this environment, access list 110 is an output access list assigned with the acl=110 AVP. In the show line listing, AccO refers to output access list 110. In this case, AccI is not set (indicated by a dash).
2.3 Implementing Local Router AuthenticationThese processes help you to establish local-based router authentication as illustrated in Figure 2-2:
1. Configure basic router access.
2. Verify local authentication operation.
Figure 2-2 Local-Based Router Environment
3505
3
IP
Local-basedVTY access (Telnet)
2-8Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.3 Implementing Local Router Authentication
Step 1 Configure basic router access.
Include the following Cisco IOS configuration commands in your configuration to enforce local on all interfaces except the console port:
Note The NO_AUTHENT list disables authentication on the console port. See “A.2 Router AAA Command Implementation Descriptions” in Appendix A, “AAA Device Configuration Listings” for notes regarding Cisco IOS AAA commands.
Step 2 Verify local authentication operation.
a. To verify user access, initiate a login process as follows:
maui-rtr-03#login
User Access Verification
Username: rtr_superPassword: <password>
maui-rtr-03#
2-9Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.4 Implementing Local Router Authorization
b. To determine that local dial access authentication is operating correctly, enter the debug aaa authentication command as follows:
maui-rtr-03#debug aaa authenticationAAA Authentication debugging is onmaui-rtr-03#show debugGeneral OS: AAA Authentication debugging is on
2.4 Implementing Local Router AuthorizationLocal router authorization is implemented through router command authorization configuration. The following example:
• Shows how to create two privilege levels (1 and 15) with local access and how to control the access to global configuration mode.
• Provides a method to gain access by using the enable password if the local login fails.
Follow a methodical approach when dealing with TACACS+ in routers to prevent the need to perform password recovery.
Note Some versions of boot ROMs do not recognize all AAA commands. Be sure to disable AAA authentication and authorization before changing to boot ROM mode. For configuration notes regarding disabling AAA to access boot ROM mode, see Appendix B, “AAA Impact on Maintenance Tasks.”
These processes are intended to help you to accomplish the following tasks:
1. Configure local router authorization at privilege level 15.
2. Verify local router authorization is set to privilege level 15.
2-10Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.4 Implementing Local Router Authorization
Step 1 Configure local router authorization at privilege level 15.
Include the following Cisco IOS configuration commands in your configuration to enforce local authorization at privilege level 15 on all interfaces except the console port:
Note You must first log out, and then log back into the router following the inclusion of the aaa authorization commands 15 local if-authenticated command (illustrated in the preceding configuration fragment). Doing this ensures that you log in as the user rtr_super (in this case study example). The NO_AUTHENT list disables authentication on the console port. The NO_AUTHOR list disables EXEC and command authorization on the console port. See “A.2 Router AAA Command Implementation Descriptions” in Appendix A, “AAA Device Configuration Listings” for notes regarding key Cisco IOS AAA commands.
Step 2 Verify local router authorization is set to privilege level 15.
Enter the following commands to verify correct authorization:
maui-rtr-03#debug aaa authorizationAAA Authorization debugging is onmaui-rtr-03#show debugGeneral OS: AAA Authorization debugging is on
maui-rtr-03#login
User Access Verification
Username: rtr_superPassword:
The following tests illustrate operations described in “2.4 Implementing Local Router Authorization” and include relevant router output.
1. User rtr_super is authorized EXEC shell access.
2. User rtr_super logs is assigned priv-lvl 15 AVP.
3. User rtr_super successfully performs privilege level 15 command.
2-11Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.5 Implementing Local Router Accounting
The following diagnostic results are presented in the order in which they are generated during the authorization process. Specific output fragments are differentiated with brief explanatory notes to help you identify relevant information.
Note The debug command output can vary depending on Cisco IOS versions.
1. User rtr_super is authorized EXEC shell access.
2. User rtr_super logs is assigned priv-lvl 15 AVP.
Router debug output:
Mar 13 14:09:00.511 CST: AAA/AUTHOR/EXEC: Processing AV service=shellMar 13 14:09:00.511 CST: AAA/AUTHOR/EXEC: Processing AV cmd*Mar 13 14:09:00.511 CST: AAA/AUTHOR/EXEC: Processing AV priv-lvl=15Mar 13 14:09:00.511 CST: AAA/AUTHOR/EXEC: Authorization successfulMar 13 14:09:01.648 CST: tty2 AAA/AUTHOR/CMD (2192867088): Port='tty2' list='' service=CMD
3. User rtr_super successfully performs privilege level 15 command.
Router debug output:
Mar 13 14:09:01.648 CST: AAA/AUTHOR/CMD: tty2 (2192867088) user='rtr_super'Mar 13 14:09:01.648 CST: tty2 AAA/AUTHOR/CMD (2192867088): send AV service=shellMar 13 14:09:01.648 CST: tty2 AAA/AUTHOR/CMD (2192867088): send AV cmd=configureMar 13 14:09:01.648 CST: tty2 AAA/AUTHOR/CMD (2192867088): send AV cmd-arg=terminalMar 13 14:09:01.648 CST: tty2 AAA/AUTHOR/CMD (2192867088): send AV cmd-arg=<cr>Mar 13 14:09:01.648 CST: tty2 AAA/AUTHOR/CMD (2192867088): found list "default"Mar 13 14:09:01.648 CST: tty2 AAA/AUTHOR/CMD (2192867088): Method=LOCALMar 13 14:09:01.648 CST: AAA/AUTHOR (2192867088): Post authorization status = PASS_ADD
2.5 Implementing Local Router AccountingThese processes help you to accomplish the following tasks:
1. Configure basic local accounting for router access.
2. Verify and troubleshoot local accounting from VTY (Telnet) based access to the router.
2-12Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.5 Implementing Local Router Accounting
Step 1 Configure basic local accounting for router access.
Include the following Cisco IOS configuration commands in your configuration to construct local based router accounting for EXEC and command authorization for privilege level 15 commands:
Note In the preceding configuration fragment, the start-stop option is entered for EXEC shell sessions and the stop-only option is entered for privilege-level 15 commands. The router sends a start packet in the beginning of a shell service and a stop packet when the session terminates. A stop packet is only sent upon completion of a privilege level 15 command in the router. Additionally, note the use of the NO_ACCOUNT list to disable AAA accounting on the console port.
Step 2 Verify and troubleshoot local accounting from VTY (Telnet) based access to the router.
Enter the debug aaa accounting command to verify local router accounting is operating as expected. The following EXEC sequence illustrates that the appropriate commands are enabled:
maui-rtr-03#show debugGeneral OS:AAA Accounting debugging is on
The following tests illustrate operations described in “2.5 Implementing Local Router Accounting” and include relevant router output.
1. User rtr_super is authorized EXEC shell access.
2. User rtr_super successfully performs configure terminal, a privilege level 15 command.
The following diagnostic results are presented in the order in which they are generated during a typical authorization and command request process. Specific output fragments are separated out with brief explanatory notes to help you identify relevant information.
2-13Cisco AAA Implementation Case Study
Chapter 2 Implementing the Local AAA Subsystem2.5 Implementing Local Router Accounting
Note The debug command output can vary depending on Cisco IOS versions.
1. User rtr_super is authorized EXEC shell access.
Router debug output:
Apr 11 16:48:32.483: AAA/ACCT/EXEC/START User rtr_super, port tty3Apr 11 16:48:32.483: AAA/ACCT/EXEC: Found list "default"Apr 11 16:48:32.483: AAA/ACCT/EXEC/START User rtr_super, Port tty3, task_id=362 start_time=955471712 timezone=CST service=shellApr 11 16:48:32.483: AAA/ACCT: user rtr_super, acct type 0 (1526108857): Method=tacacs+ (tacacs+)Apr 11 16:48:33.487: TAC+: (1526108857): received acct response status = SUCCESS
2. User rtr_super successfully performs configure terminal, a privilege level 15 command.
Router debug output:
Apr 11 16:51:52.741: AAA/ACCT/CMD: User rtr_super, Port tty3, Priv 15: "configure terminal <cr>"Apr 11 16:51:52.741: AAA/ACCT/CMD: Found list "default"Apr 11 16:51:52.741: AAA/ACCT: user rtr_super, acct type 3 (2701117300): Method=tacacs+ (tacacs+)Apr 11 16:51:53.545: TAC+: (2701117300): received acct response status = SUCCESS
2-14Cisco AAA Implementation Case Study
Cis
C H A P T E R 3
Implementing Cisco AAA Servers
This chapter describes the basic process of installing CiscoSecure for UNIX (CSU). See Chapter 1, “Cisco AAA Case Study Overview” for information regarding this case study’s network requirements and environment details for this case study. Figure 3-1 illustrates the general networking environment in which this CSU is implemented.
Network elementmanagement server (NTP, Syslog, SNMP)
AAAserver
Internetfirewall
Defaultgateway
Cisco AS5x00with integrated
modems
PSTNPRI linesAnalog lines
DNSserver
Oracle dB server
IP intranet
3-1co AAA Implementation Case Study
Chapter 3 Implementing Cisco AAA Servers3.1 Installing CiscoSecure for UNIX with Oracle
3.1 Installing CiscoSecure for UNIX with OracleThese processes of help you to install CiscoSecure for UNIX:
• 3.1.1 Creating Oracle Tablespace
• 3.1.2 Verifying the Oracle Database Instance
• 3.1.3 Installing CiscoSecure for UNIX
• 3.1.4 Creating and Verifying Basic User Profile
3.1.1 Creating Oracle TablespaceYou must create an Oracle tablespace with a minimum size of 200 MB. The notes listed in this section are for reference.
Note Ensure that an experienced Oracle database administrator (DBA) tunes and configures the database.
For detailed Oracle installation notes, go to the following location:
<CSUserver>$su - oracleSun Microsystems Inc. SunOS 5.5.1 Generic May 1996<CSUserver>$$ORACLE_HOME/bin/svrmgrl Oracle Server Manager Release 2.3.4.0.0 - Production Copyright (c) Oracle Corporation 1994, 1995. All rights reserved. Oracle7 Server Release 7.3.4.0.1 - ProductionWith the distributed optionPL/SQL Release 2.3.4.0.0 - Production SVRMGR>connect internalConnected.SVRMGR>create tablespace cstb datafile '/export/home/ORADATA/cs.dbf' size 200m;Statement processed.SVRMGR>create user csecure identified by csecure default tablespace cstb;Statement processed.SVRMGR>grant dba to csecure identified by csecure;Statement processed.SVRMGR>exitServer Manager complete.
3-2Cisco AAA Implementation Case Study
Chapter 3 Implementing Cisco AAA Servers3.1 Installing CiscoSecure for UNIX with Oracle
3.1.2 Verifying the Oracle Database InstanceBefore you install CiscoSecure for UNIX, make sure the Oracle server is running and you have the following five pieces of information:
• The Oracle user account for CiscoSecure (csecure)
• The password for the Oracle account (csecure)
• TNS service name for the Oracle server (ciscosj)
• The location of $ORACLE_HOME (/opt/oracle/product/7.3.4)
• The number of Connections to use for ORACLE RDBMS (50)
Step 1 To verify the software directory environment variable ($ORACLE_HOME) where Oracle is installed, enter the following command. Log in to the $ORACLE_HOME as follows:
The command returns the ora_smon_<SID> process if the server is running. Notice the database instance specification of ciscosj. If the server is down, log in with the Oracle UNIX account (in this case, with username of csecure and password of csecure) and start the database by using Server Manager (svrmgrl) and Oracle listener (lsnrctl) as follows:
<CSUserver>$$ORACLE_HOME/bin/svrmgrlSVRMGR>connect internalSVRMGR>startupORACLE instance started.Total System Global Area 4576056 bytesFixed Size 39816 bytesVariable Size 4118448 bytesDatabase Buffers 409600 bytesRedo Buffers 8192 bytesDatabase mounted.Database opened.
3-3Cisco AAA Implementation Case Study
Chapter 3 Implementing Cisco AAA Servers3.1 Installing CiscoSecure for UNIX with Oracle
<CSUserver>$$ORACLE_HOME/bin/lsnrctl startLSNRCTL for Solaris:Version 2.3.4.0.0 - Production on 12-APR-00 09:40:46
Copyright (c) Oracle Corporation 1994. All rights reserved.
TNSLSNR for Solaris:Version 2.3.4.0.0 - ProductionSystem parameter file is /opt/oracle/product/7.3.4/network/admin/listener.oraLog messages written to /opt/oracle/product/7.3.4/network/log/listener.logListening on:(ADDRESS=(PROTOCOL=ipc)(DEV=10)(KEY=ciscoaus))Listening on:(ADDRESS=(PROTOCOL=ipc)(DEV=13)(KEY=PNPKEY))Listening on:(ADDRESS=(PROTOCOL=tcp)(DEV=15)(HOST=172.22.53.204)(PORT=1521))
Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=ciscosj))STATUS of the LISTENER------------------------Alias LISTENERVersion TNSLSNR for Solaris:Version 2.3.4.0.0 - ProductionStart Date 12-APR-00 09:40:50Uptime 0 days 0 hr. 0 min. 0 secTrace Level offSecurity OFFSNMP OFFListener Parameter File /opt/oracle/product/7.3.4/network/admin/listener.oraListener Log File /opt/oracle/product/7.3.4/network/log/listener.logServices Summary... ciscoaus has 1 service handler(s)The command completed successfully
Step 3 To verify that the Oracle database account information is created for CiscoSecure by the DBA, enter Security Manager using the sqlplus process:
<CSUserver>$sqlplus csecure/csecure@ciscosj SQL>select * from user_sys_privs;
USERNAME PRIVILEGE ADM------------------------------ ---------------------------------------- ---CSECURE UNLIMITED TABLESPACE NO
Note Ensure that the assigned resource role/privilege for the username and password is as shown.
The command returns a table with a column listing the privileges granted to the Oracle database account. The default tablespace assigned to the Oracle database account must be at least 200MB. The size is verified by the installation script.
Step 4 To confirm tnsnames service is operating correctly, invoke the tnsping utility as follows:
<CSUserver>$$ORACLE_HOME/bin/tnsping ciscosj
TNS Ping Utility for Solaris: Version 2.3.4.0.0 - Production on 29-FEB-00 09:25:28
Copyright (c) Oracle Corporation 1995. All rights reserved.
Attempting to contact (ADDRESS=(PROTOCOL=TCP)(Host=CSUserver)(Port=1521))OK (80 msec)
3-4Cisco AAA Implementation Case Study
Chapter 3 Implementing Cisco AAA Servers3.1 Installing CiscoSecure for UNIX with Oracle
Step 5 Ensure the number of Oracle RDBMS connections assigned to CiscoSecure is less than the PROCESSES variable defined in the initciscosj.ora file. This parameter specifies the maximum number of user processes that can simultaneously connect to an Oracle Server. If the value for PROCESSES is set to 20, then only 13 or 14 concurrent connections can be assigned to CiscoSecure. For this case study, at least four of the connections are reserved for mandatory background server processes. In addition, the PROCESSES variable is set to 50 and the number of Oracle RDBMS connections is set to 50 during the installation.
3.1.3 Installing CiscoSecure for UNIXThe general steps and output that follow apply to the installation dialog for CiscoSecure for UNIX (CSU) on a Sun Solaris workstation. Installation consists of the following steps:
1. Start the CSU installation process by invoking the pkgadd program.
2. Configure CSU logging by editing /etc/syslog.conf to enable AAA syslog function:
3. Create /var/log/csuslog file.
4. Configure the AAA server for maximum level debugging.
5. Restart the AAA server.
6. Restart the syslog daemon.
3-5Cisco AAA Implementation Case Study
Chapter 3 Implementing Cisco AAA Servers3.1 Installing CiscoSecure for UNIX with Oracle
Step 1 Start the CSU installation process by invoking the pkgadd program.
The process that follows illustrates the general installation sequence. Extraneous output was omitted where noted for brevity.
Note The following installation process requires approximately 20 minutes.
<CSUserver>$pkgadd -d CiscoSecure-2.3.3.solaris The following packages are available: 1 CSCEacs CiscoSecure Access Control Software (sun4) 2.3(3) Select package(s) you wish to process (or 'all' to processall packages). (default: all) [?,??,q]:1 Processing package instance <CSCEacs> from </opt/install/ciscosecure/CiscoSecure-2.3.3.solaris> CiscoSecure Access Control Software(sun4) 2.3(3) Copyright(c) 1996-1999 Cisco Systems, Inc.CiscoSecure Access Control ServerVersion 2.3(3)All Rights Reserved. Copyright (c) 1994-1999 Netscape Communications CorporationCopyright (c) 1988-1999 Sybase, Inc.Trade Mark WebLogic, Inc. Notice:By using this product, you agree to be bound by the terms ofthe license supplied with this product. If you do not agreeto these terms, promptly return the unused product, manuals,related equipment, and hardware (with proof of purchase) tothe place of purchase for a full refund. To install this product, you must agree to accept the termsof the enclosed license [accept=y,exit=n,exit=q]: y checking patches... ************************************************************************* Notice: ** This installation program saves your Database files from a previous ** CiscoSecure install. If you have not installed CiscoSecure before, ** you should answer YES to the next question. If you have performed ** a 'package remove' and are installing a new version of CiscoSecure ** and want to retain your previous Database files, you should answer ** NO to the next question. ************************************************************************* Is this a new install (y/n/q) (default: yes, q to quit)?y Enter the directory name in which to install CiscoSecure [?,q]/opt/ciscosecure
3-6Cisco AAA Implementation Case Study
Chapter 3 Implementing Cisco AAA Servers3.1 Installing CiscoSecure for UNIX with Oracle
IP Address to use for CiscoSecure (default: 172.23.25.41) [?,q] If the hostname of this server is not the same as its fully qualified domainname (FQDN), enter the FQDN, e.g., www.cisco.com. Otherwise, press enterto use the default (default: CSUserver) [?,q] Enter the AAA Server License key (default: <none>) [?,q] Enter the TACACS+ NAS name to use (default: <none>) [?,q] Enter the TACACS+ NAS Secret key (default: SECRET12345) [?,q]ciscorules Select any or all Token Cards to use 1 CryptoCard 2 Secure-Computing SafeWord 3 SDI SDI Token Card Enter selection (default: none) [?,??,q]: Choose Database 1 SQLAnywhere Sybase SQL Anywhere 2 ORACLE Oracle Enterprise 3 SYBASE Sybase Enterprise Enter selection (default: SQLAnywhere) [?,??,q]:2 Enter the username for the ORACLE DB account [?,q]csecure Enter the password for the ORACLE DB account [?,q]csecure Enter the TNS service name for the Oracle Server [?,q]ciscosj Enter the ORACLE_HOME directory [?,q]/opt/oracle/product/7.3.4 Enter an available TCP/IP Port to be reserved for the CiscoSecure DB Serverprocess (default: 9900) [0-65535,?,q] Enter a unique name for the CiscoSecure DB Server Process (default:CSdbServer) [?,q] Enter the number of Connections to use for ORACLE RDBMS (default: 4) [?,q]50 Enter the directory Path to use for the AAA server profile caching(default: /, q to quit)? Modify any selections below? New CiscoSecure Install YES CiscoSecure Directory /opt/ciscosecure CiscoSecure IP Address 172.23.25.41 CiscoSecure Web Server Name CSUserver Profile Cache Directory / AAA License Key <none> TACACS+ NAS Name <none> TACACS+ NAS Secret Key SECRET12345 Token Cards selected none Data Base ORACLE DB User Account Name csecure DB User Account Passwd csecure Oracle TNS Name ciscosj Oracle Home /opt/oracle/product/7.3.4 CiscoSecure DB Server IP Address 172.23.25.41 CiscoSecure DB Server Port 9900 CiscoSecure DB Server Proc Name CSdbServer
3-7Cisco AAA Implementation Case Study
Chapter 3 Implementing Cisco AAA Servers3.1 Installing CiscoSecure for UNIX with Oracle
DB Server Connections 50 Modify any values [y,n,q]: n cs_install.log being written to /tmp directory Using </opt/ciscosecure> as the package base directory.## Processing package information.## Processing system information. 6 package pathnames are already properly installed.## Verifying disk space requirements.## Checking for conflicts with packages already installed.## Checking for setuid/setgid programs. This package contains scripts which will be executed with super-userpermission during the process of installing this package. Do you want to continue with the installation of <CSCEacs> [y,n,?]y Installing CiscoSecure Access Control Software as <CSCEacs> ## Executing preinstall script.## Installing part 1 of 1.
Note Process output is omitted at this point because it is not relevant to the installation task presented in this chapter.
[ verifying class <TSERVER> ]## Executing postinstall script. Creating the initial database tables and views........ Loading properties from /opt/ciscosecure/config/CSConfig.iniFinished loading properties.Data Source = ORACLEDriver Type = JDBC-Weblogic-Oracle URL = jdbc:weblogic:oracle:ciscosj username = csecure password = ******** Connected to jdbc:weblogic:oracle:ciscosjDriver Weblogic, Inc. Java-OCI JDBC Driver (weblogicoci26)Version 2.5.4 sql = select tablespace_name, floor(sum(bytes)/(1024*1024)) from sys.dba_free_space where tablespace_name = (select default_tablespace from sys.dba_users whereusername = USER) group by tablespace_name Total free space in CSTB tablespace is 199 MB.Creating /opt/ciscosecure/utils/sql.scripts/ora_init.sql%Executing SQL statements..
3-8Cisco AAA Implementation Case Study
Chapter 3 Implementing Cisco AAA Servers3.1 Installing CiscoSecure for UNIX with Oracle
Note Process output is omitted at this point because it is not relevant to the installation task presented in this chapter.
Successfully done. Initializing RADIUS data in the database........ Loading properties from /opt/ciscosecure/config/CSConfig.iniFinished loading properties.Data Source = ORACLEDriver Type = JDBC-Weblogic-Oracle URL = jdbc:weblogic:oracle:ciscosj username = csecure password = ******** Connected to jdbc:weblogic:oracle:ciscosjDriver Weblogic, Inc. Java-OCI JDBC Driver (weblogicoci26)Version 2.5.4 Radius data version: 23Adding SERVER_LISTAdding DICTIONARY_LISTAdding SERVER.172.23.25.41Adding DICTIONARY.IETFAdding DICTIONARY.CiscoAdding DICTIONARY.AscendAdding DICTIONARY.Cisco11.1Adding DICTIONARY.Cisco11.2Adding DICTIONARY.Cisco11.3Adding DICTIONARY.Ascend5No update to dictionary listUpdate radius version: INSERT INTO cs_id (id, type) VALUES (?, ?)
Successfully done. Installation is complete. However, further configuration may be necessary.For more information on the steps necessary to finish configuration, readthe /opt/ciscosecure/DOCS/README.txt file. Results of this install are saved in the /tmp/cs_install.log file and in/opt/ciscosecure/logfiles/cs_install.log.
NOTE: For AAA Server tuning, refer to http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/cs_unx/csu23rg/app_b.htm#xtocid192003
Installation of <CSCEacs> was successful.
Step 2 Configure CSU logging by editing /etc/syslog.conf to enable AAA syslog function:
Enter the following command:
#added by [email protected] on 02/28/00local0.debug /var/log/csuslog
Note Do not use whitespace to separate the above statements in /etc/syslog.conf. Use only tabs.
Step 3 Create /var/log/csuslog file.
3-9Cisco AAA Implementation Case Study
Chapter 3 Implementing Cisco AAA Servers3.1 Installing CiscoSecure for UNIX with Oracle
Enter the touch command to create the csulog file.
Step 4 Configure the AAA server for maximum level debugging.
Modify /opt/ciscosecure/config/CSU.cfg as follows:
NUMBER config_logging_configuration = 0x7ffffffff
Step 5 Restart the AAA server.
Enter the following command to restart the AAA server:
<CSUserver>$/etc/rc0.d/K80CiscoSecure
Stopping CiscoSecure Processes:
CiscoSecure AutoRestart Stopped Fast Track Server Stopped Fast Track Admin Program Stopped Acme Server Stopped AAA Server Stopped DBServer Stopped
<CSUserver>$/etc/rc2.d/S80CiscoSecure
Starting CiscoSecure Processes:
Fast Track Admin Started FastTrack Server (Delayed Start) DBServer Started AAA Server starts in 15 Seconds: 123456789012345 AAA Server Started Acme Server Started Cisco AutoRestart started
Step 6 Restart the syslog daemon.
Enter the follow command to restart the syslog daemon:
Caution The example configuration fragments used throughout this chapter include IP addresses, passwords, authentication keys, and other variables that are specific to this case study. If you use these fragments as foundations for you own configurations, be sure that your specifications apply to your environment.
Note See Chapter 2, “Implementing the Local AAA Subsystem,” for specifics of local AAA implementation. See “1.1 AAA Technology Summary,” in Chapter 1 for brief definitions of authentication, authorization, and accounting as they relate to AAA security implementation.
Figure 4-1 provides the general scenario this case study is built around and illustrates the server-based AAA components, including a AAA server and its associated AAA database.
The following section focuses on server-based dialup authentication configuration. In this context, server-based refers to actions dependent upon an external AAA server. These actions are described in a series of general steps along with related commands, server configurations, and diagnostic steps as appropriate. Figure 4-2 illustrates a simplified TACACS+ server-based dial environment.
These steps help you to accomplish the following tasks:
1. Configure TACACS+ server-based authentication on NAS.
2. Configure a user profile in the database.
3. Verify the AAA server-based user configuration.
4. Verify and troubleshoot authentication from the AAA server.
5. Verify and troubleshoot PPP authentication from the NAS.
Step 1 Configure TACACS+ server-based authentication on NAS.
Include the following Cisco IOS configuration commands in your configuration to enforce server-based dial access authentication control with TACACS+:
aaa new-modelaaa authentication login default group tacacs+ aaa authentication ppp default if-needed group tacacs+ !tacacs-server host 172.22.53.101 key ciscorules
Note See “A.3 NAS AAA Command Implementation Descriptions” in Appendix A, “AAA Device Configuration Listings” for notes regarding key Cisco IOS AAA commands.
Step 2 Configure a user profile in the database.
Create a user in the AAA server by entering the following AddProfile command:
<CSUserver>$/opt/ciscosecure/CLI/AddProfile -p 9900 -u tac_dial -pw pap,ciscorules –a 'service=ppp{\n protocol=ip{\n set addr-pool=default \n set inacl=110 \n}\n protocol=lcp {\n }\n }\n’
Caution When entering AddProfile to create users or groups, it is possible to successfully create users or groups that have invalid database parameters that result in profile errors viewable in /var/log/csuslog.
Step 3 Verify the AAA server-based user configuration.
Enter this server command to view the AAA server-based user configuration:
Step 4 Verify and troubleshoot authentication from the AAA server.
Enter the tail command:.
<CSUserver>$tail -f /var/log/csuslog
Note See “C.1 Server-Based TACACS+ Dialup Authentication Diagnostics” for a description of relevant diagnostic output.
Step 5 Verify and troubleshoot PPP authentication from the NAS.
Enter the debug aaa authentication and debug ppp authentication commands to confirm authentication from the NAS perspective.
Note See “C.1 Server-Based TACACS+ Dialup Authentication Diagnostics” for relevant diagnostic output.
4.2 Implementing Server-Based TACACS+ Dialup AuthorizationThis section focuses on implementing of server-based dialup authorization and presents applicable configuration segments, server commands and file listings, and diagnostic steps.
These steps help you to accomplish the following tasks:
1. Configure TACACS+ server-based authorization on the NAS.
2. Configure a user profile in the database.
3. Verify the AAA server-based user configuration.
4. Verify and troubleshoot a shell-initiated PPP session authorization from the AAA server.
5. Verify and troubleshoot shell-initiated PPP authorization on the NAS.
Step 1 Configure TACACS+ server-based authorization on the NAS.
Include the following Cisco IOS configuration commands in your configuration to enforce server-based dial access authorization with TACACS+:
aaa new-modelaaa authentication login default group tacacs+aaa authentication ppp default if-needed group tacacs+aaa authorization exec default group tacacs+ if-authenticatedaaa authorization network default group tacacs+ if-authenticated!tacacs-server host x.x.x.x key ciscorules
Note See “A.3 NAS AAA Command Implementation Descriptions” in Appendix A, “AAA Device Configuration Listings” for notes regarding key Cisco IOS AAA commands.
4.3 Implementing Server-Based RADIUS Dialup AuthenticationThis section focuses on the configuration of server-based, RADIUS dialup authentication configuration. In this context, server-based refers to actions that depend on an external AAA server. Figure 4-3 illustrates a simplified server-based dial environment.
These steps help you to accomplish the following tasks:
1. Configure RADIUS server-based authentication on access server.
2. Configure a user profile in the database.
3. Verify the AAA server-based user configuration.
4. Enter the debug aaa authentication and debug ppp authorization commands to confirm authentication from NAS perspective.
Step 1 Configure RADIUS server-based authentication on access server.
Include the following Cisco IOS configuration commands in your configuration to enforce server-based dial access authentication control with RADIUS:
aaa new-modelaaa authentication login default group radius aaa authentication ppp default if-needed group radius !interface Group-Async1 ip unnumbered Loopback0 no ip directed-broadcast encapsulation ppp ip tcp header-compression passive no logging event link-status dialer in-band dialer idle-timeout 900 async mode interactive no snmp trap link-status peer default ip address pool default no fair-queue no cdp enable ppp max-bad-auth 3 ppp authentication pap chap group-range 1 48!line 1 48 exec-timeout 48 0 autoselect during-login autoselect ppp absolute-timeout 240 modem InOut modem autoconfigure type mica transport preferred telnet transport input all transport output lat pad telnet rlogin udptn v120 lapb-ta
Note See “A.3 NAS AAA Command Implementation Descriptions” in Appendix A, “AAA Device Configuration Listings” for notes regarding key Cisco IOS AAA commands.
Step 2 Configure a user profile in the database.
a. Create a RADIUS NAS configuration by entering the following AddProfile command:
<CSUserver>$/opt/ciscosecure/CLI/AddProfile -p 9900 -u NAS.172.22.53.105 -a 'NASName="172.22.53.105"\nSharedSecret="ciscorules"\nRadiusVendor="Cisco"\nDictionary="DICTIONARY.Cisco"\n }\n'
b. Create a user in the AAA server by entering the following AddProfile command:
Step 1 Configure RADIUS server-based authorization on the NAS.
Include the following Cisco IOS configuration commands in your configuration to enforce RADIUS authorization assigning access-list 110 to the user, rad_dial:
aaa new-modelaaa authentication login default group radiusaaa authentication ppp default if-needed group radiusaaa authorization exec default group radiusaaa authorization network default group radius if-authenticated!radius-server host 172.22.53.201 auth-port 1645 acct-port 1646 key ciscorules!access-list 110 permit tcp any any eq telnetaccess-list 110 permit tcp any any eq ftpaccess-list 110 permit tcp any any eq ftp-dataaccess-list 110 deny tcp any any
Note See “A.3 NAS AAA Command Implementation Descriptions” in Appendix A, “AAA Device Configuration Listings” for notes regarding key Cisco IOS AAA commands.
Step 2 Configure a user profile in the database.
Create a user in the AAA server by entering the following AddProfile command:
This section focuses on how to configure and verify TACACS+ Cisco IOS authentication by using a router and a AAA server. Figure 4-4 illustrates a simplified server-based VTY-access environment for a router.
These steps help you to accomplish the following tasks:
1. Configure TACACS+ server-based authentication on the router.
2. Configure and verify the group rtr_basic:
3. Create the member rtr_test and assign this user to group rtr_basic.
4. Verify user rtr_test.
5. Log in to the router and verify proper authentication.
Step 1 Configure TACACS+ server-based authentication on the router.
Include the following Cisco IOS configuration commands in your configuration to enforce AAA server-based command authorization on a router (excluding the console port):
Step 5 Log in to the router and verify proper authentication.
Enter the login command to access the router command interface and monitor the output of debug aaa authentication from a separate shell session. Monitor the output of the AAA server by consulting the csuslog file using the tail command.
Note See “C.5 Server-Based TACACS+ Router Authentication Diagnostics.”
4.6 Implementing Server-Based TACACS+ Router AuthorizationThe following examples, including authorization-related IOS command listings and AAA server profiles, illustrate how to define administrative control over Cisco routers. Three administrative groups are created with low (rtr_low), medium (rtr_tech), and high (rtr_super) access. The default_cmd AVP (defined in the AAA server profile) is used to control access to privilege level 15 commands. In this case, privilege level 15 is the highest level of command access privilege allowed and is reserved for super users or network managers. Table 4-1 compares the Cisco IOS command permissions associated with each of the administrative groups defined in this section.
Figure 4-5 provides a flowchart that depicts AAA server-based authentication and authorization between a router and an AAA server. Troubleshooting and verifying is divided into three stages: authentication, EXEC authorization and command authorization. Each stage is accompanied by information particular to that stage:
• Cisco IOS Configuration Fragments (on left)
• Troubleshooting and verification methods for the router and AAA server (on right)
Table 4-1 Group Profile Command Summary
Group
Cisco IOS Command rtr_super rtr_tech rtr_lowdebug all Denied Denied Denied
Note Some versions of boot ROMs do not recognize all AAA commands. Be sure to disable AAA authentication and authorization before changing to boot ROM mode. For configuration notes regarding disabling AAA to access boot ROM mode, see Appendix B, “AAA Impact on Maintenance Tasks.”
Step 1 Configure TACACS+ server-based authorization from the console port on the router.
Include the following Cisco IOS configuration commands in your configuration to enforce router-based security with TACACS+:
Caution The example configuration fragments used throughout this chapter include IP addresses, passwords, authentication keys, and other variables that are specific to this case study. If you use these fragments as foundations for you own configurations, be sure that your specifications apply to your environment.
Note See “1.1 AAA Technology Summary,” in Chapter 1 for brief definitions of authentication, authorization, and accounting as they relate to AAA security implementation.
5.1 Implementing Server-Based RADIUS Dial AccountingThe information compiled by the Cisco IOS client focuses on the performance of intermediate systems in terms of AAA accounting packet output, disconnect cause codes, elapsed time, packets in/out, and other useful information. This section addresses configuring server-based RADIUS dial accounting on the AAA server and the Cisco IOS client or network access server (NAS).
These steps help you to accomplish the following tasks:
1. Configure the server-based RADIUS dial accounting on the AAA server.
2. Configure server-based RADIUS dial accounting on the NAS.
3. Verify and troubleshoot server-based accounting from the AAA server by using an SQL query to Oracle dB instance.
4. Verify AAA accounting from the NAS.
Step 1 Configure the server-based RADIUS dial accounting on the AAA server.
Include the following configuration line in /opt/ciscosecure/CLI/config/CSU.cfg to enable group membership accounting:
Step 2 Configure server-based RADIUS dial accounting on the NAS.
Include the following Cisco IOS commands in your configuration file to support dialup authentication, authorization, and accounting.
aaa new-modelaaa authentication login default group radius localaaa authentication ppp default if-needed group radius localaaa authorization exec default group radius if-authenticatedaaa accounting exec default stop-only group radiusaaa accounting network default stop-only group radius
Step 3 Verify and troubleshoot server-based accounting from the AAA server by using an SQL query to Oracle dB instance.
The following examples illustrate the use of SQL query commands to monitor user rad_dial being disconnected due to idletime configured with the line configuration session-timeout command in the NAS:
<CSUServer>$/export/home/oracle> sqlplus
SQL*Plus: Release 3.3.4.0.1 - Production on Mon Apr 17 17:41:52 2000
Copyright (c) Oracle Corporation 1979, 1996. All rights reserved.
Enter user-name:csecure/csecure@ciscoausConnected to:Oracle7 Server Release 7.3.4.0.1 - ProductionPL/SQL Release 2.3.4.0.0 - Production
SQL> select * from cs_accounting_log where blob_data like '%rad_dial%';
Note The disc-cause and disc-cause-ext output both reflect idle timeouts from Table 5-1 listed in “5.3 AAA Disconnect Cause Code Descriptions” in this chapter.
Step 4 Verify AAA accounting from the NAS.
Review and verify user rad_dial disconnecting session from the NAS by using the Cisco IOS show caller user and debug aaa accounting commands.
The following example illustrates local accounting diagnostic output in which user rad_dial is disconnected because of a line configuration session-timeout command configured in the NAS:
Note The disc-cause and disc-cause-ext both reflect idle timeouts from Table 5-1 listed in “5.3 AAA Disconnect Cause Code Descriptions” in this chapter.
Step 2 Configure server-based TACACS+ EXEC and command level accounting on the router.
Include the following Cisco IOS commands in your configuration file to enable router EXEC and command AAA authentication, authorization, and accounting:
aaa new-modelaaa authentication login default group tacacs+ localaaa authentication login NO_AUTHEN noneaaa authorization exec default group tacacs+ if-authenticatedaaa authorization exec NO_AUTHOR noneaaa authorization commands 15 default group tacacs+aaa authorization commands 15 NO_AUTHOR noneaaa accounting exec default stop-only group tacacs+aaa accounting commands 15 default stop-only group tacacs+
line con 0 authorization commands 15 NO_AUTHOR authorization exec NO_AUTHOR login authentication NO_AUTHEN
Note Authentication and authorization is disabled on the console port with the use of the NO_AUTHEN and NO_AUTHOR named lists.
Step 3 Verify and troubleshoot server-based accounting from the AAA Server with SQL query to Oracle dB instance.
The following example illustrates the use of the SQL query select command to monitor user rtr_geek entering the configure terminal privilege level 15 command:
SQL>select * from cs_accounting_log where blob_data like '%rtr_geek%';
Step 4 Verify and troubleshoot server-based accounting operation from the router.
Enter the configure terminal command to test AAA accounting behavior as follows (be sure the debug aaa accounting command is enabled):
maui-nas-03#show debugGeneral OS: AAA Accounting debugging is onmaui-nas-03#configure terminalEnter configuration commands, one per line. End with CNTL/Z.maui-nas-03(config)#^Z
This debug command output results from entering the configure terminal command:
*Apr 17 18:14:45.722 CST: AAA/ACCT/CMD: User rtr_geek, Port tty0, Priv 15: "configure terminal <cr>"*Apr 17 18:14:45.722 CST: AAA/ACCT/CMD: Found list "default"*Apr 17 18:14:45.726 CST: AAA/ACCT: user rtr_geek, acct type 3 (1057208544): Method=tacacs+ (tacacs+)*Apr 17 18:14:45.930 CST: TAC+: (1057208544): received acct response status = SUCCESS
5.3 AAA Disconnect Cause Code DescriptionsTable 5-1 lists the disconnect codes reported by Cisco AAA accounting records. The disconnect cause codes are referred to in “5.1 Implementing Server-Based RADIUS Dial Accounting.”
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
• 6.2 Troubleshooting AAA Implementation
• 6.3 AAA Troubleshooting Basics
• 6.4 Troubleshooting Scenarios
6-1co AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.1 Overview of Authentication and Authorization Processes
6.1 Overview of Authentication and Authorization ProcessesBefore 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
Internet
3508
9
Clients Modems
Network elementmanagement server (NTP, Syslog, SNMP)
AAAserver
Internetfirewall
Defaultgateway
Cisco AS5x00with integrated
modems
PSTNPRI linesAnalog lines
DNSserver
Oracle dB server
IP intranet
6-2Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.1 Overview of Authentication and Authorization Processes
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
2781
5
Networkaccess server
TACACS+query
Valid user
Pass
Password = ?
Pass
Pass
Authorization
SQL Validpassword
Oracledatabase
Pass
Pass
Fail
Fail
Fail
Result
CiscoSecureACS
6-3Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.1 Overview of Authentication and Authorization Processes
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.
user=rad_dial{
reply_attributes={6=66=27=1}}
Networktime
Access requestSend username password
Access accept
User-Service-Type (Shell-User)
User-Service-Type (Framed-User)
Framed-Protocol = PPP
3504
8
Aut
hent
icat
ion
and
Aut
horiz
atio
n
AAA ServerUser Configuration
password=PAP "****"radius=Cisco{
NAS
AAAserver
6-4Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.1 Overview of Authentication and Authorization Processes
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.
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.
Access serverAAA server
CSU User Configuration
OracleDB
Aut
hent
icat
ion
Aut
horiz
atio
nA
utho
rizat
ion
user x =
password = PAP
service = shell {default_cmd = permit}
service = shell {protocol = ip {set addr-pool = default}
protocol = lcp {}
Networktime
Send start
Get user
Send user
Get pass
Send password
Pass
User = x
Send AV service = shellAV cmd*
Passuser = x
Send AV service = pppprotocol = IPaddr-pool = default
Passuser = x
Send AV service = pppprotocol = lcp
Passuser = x
Send AV service = pppprotocol = ip
Pass27
812
6-5Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.1 Overview of Authentication and Authorization Processes
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.
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.
user = y
service = shell {set autocmd = ppp negotiate}service = ppp {protocol = ip{set addr pool = default}protocol = lcp {}
Networktime
Send start
Get user
Send Abort
user = xAuthenticatepeer
Send password
Pass
LCPrequest
Pass
user = yservice = pppprotocol = lcp
Pass
CONFREQfor options
Pass 2781
3
Oracledatabase
Aut
hent
icat
ion
Net
wor
kA
utho
rizat
ion
CSU User Configuration
password = PAP
Access serverAAA server
Autoselect PPP
6-6Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.2 Troubleshooting AAA Implementation
6.2 Troubleshooting AAA ImplementationThese sections help you to accomplish the following tasks:
• 6.2.1 Troubleshooting Methodology Overview
• 6.2.2 Cisco IOS Debug Command Summary
6.2.1 Troubleshooting Methodology OverviewThe troubleshooting methodology adopted in this chapter follows these general steps:
1. Isolating the problem.
– Gathering detailed information about trouble.
– Determining the starting point and fault isolation procedures.
2. Correcting the problem.
– Making appropriate hardware, software, or configuration changes to correct the problem.
3. Verifying that the trouble is corrected.
– Performing operational tests to verify that 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 SummaryOutput 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:
• debug condition user username
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.
• debug aaa authentication
Enabling this debug command displays authentication information with TACACS+ and RADIUS client/server interaction.
• debug aaa authorization
Enabling this debug command displays authorization information with TACACS+ and RADIUS client/server interaction.
• debug aaa accounting
Enabling this debug command displays accounting information with TACACS+ and RADIUS client/server interaction.
• debug tacacs
Enabling this debug command displays TACACS+ interaction between IOS client and AAA Server.
• debug radius
6-7Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.3 AAA Troubleshooting Basics
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:
6.3 AAA Troubleshooting BasicsAAA operational diagnostic activity for access environments is divided into the following basic areas:
• Dial-based versus router-based access
• Local versus server access
• Authentication and authorization processes
These three areas can be associated with eight underlying diagnostic situations which are addressed in the following subsections:
• 6.3.1 Troubleshooting Dial-Based Local Authentication
• 6.3.2 Troubleshooting Dial-Based Server Authentication
• 6.3.3 Troubleshooting Dial-Based Local Authorization
• 6.3.4 Troubleshooting Dial-Based Server Authorization
• 6.3.5 Troubleshooting Router-Based Local Authentication
• 6.3.6 Troubleshooting Router-Based Server Authentication
• 6.3.7 Troubleshooting Router-Based Local Authorization
• 6.3.8 Troubleshooting Router-Based Server Authorization
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-8Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.3 AAA Troubleshooting Basics
6.3.1 Troubleshooting Dial-Based Local AuthenticationThe following symptoms are addressed in separate tables in this section:
• Single User Failure; Individual Dial-in User Connection Fails
• Multiple User Failure; All Dial-in Users Unable to Connect to NAS
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-9Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.3 AAA Troubleshooting Basics
6.3.2 Troubleshooting Dial-Based Server AuthenticationThe following symptoms are addressed in separate tables in this section:
• Single User Failure; Individual User Unable to Make Connection (RADIUS and TACACS+)
• Multiple User Failure; All Dial-in Users Unable to Connect to NAS (RADIUS and TACACS+)
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:
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.
6-10Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.3 AAA Troubleshooting Basics
User account password or profile expired. 1. To view profile, enter:
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:
Feature is not supported on console ports. None. Feature not supported.
6-28Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.4 Troubleshooting Scenarios
6.4 Troubleshooting ScenariosThe 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)
• 6.4.2 Isolating Invalid User Password (TACACS+ Dial-Based Server Authentication)
• 6.4.3 Isolating Non-Existent User (TACACS+ Dial-Based Server Authentication)
• 6.4.4 Isolating Missing PPP Service Definition (TACACS+ Dial-Based Server Authorization)
• 6.4.5 Isolating Defined AVPs not Being Assigned (TACACS+ Dial-Based Server Authorization)
• 6.4.6 Isolating Missing Shell Service Definition (TACACS+ Dial-Based Server Authorization)
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.
Possible Cause TACACS+ key incorrect in NAS or AAA server. See Table 6-4.
Action Complete troubleshooting steps to isolate and resolve this possible cause.
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=1088190: Jan 27 18:37:22.976 CST: AAA/AUTHEN/START (953379418): port=’tty51’ list= =30356 25154088203: Jan 27 18:37:26.216 CST: TAC+: ver=192 id=3035625154 received AUTHEN status = GETPASS088204: Jan 27 18:37:26.216 CST: AAA/AUTHEN (3035625154): status = GETPASS088205: 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 = GETPASS088207: 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=3035625154088209: 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
6-29Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.4 Troubleshooting Scenarios
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.
Possible Cause User enters invalid password. See Table 6-3.
Action Complete troubleshooting steps to isolate and resolve this possible cause.
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.
6-30Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.4 Troubleshooting Scenarios
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 = GETPASS092853: 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 = GETPASS092855: 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=543609479092857: Jan 27 22:19:08.185 CST: TAC+: ver=192 id=543609479 received AUTHEN status = FAIL092858: Jan 27 22:19:08.185 CST: AAA/AUTHEN (543609479): status = FAIL
The user session is torn down and AAA process is freed:
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.
Possible Cause User does not exist in the database. See Table 6-3.
Action Complete troubleshooting steps to isolate and resolve this possible cause.
Step 1 Gather general debug command information from the NAS. The following output is from a debug aaa authentication command executed on a NAS.
6-31Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.4 Troubleshooting Scenarios
The following output fragment shows the AAA process starting on NAS.
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:
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.4 Troubleshooting Scenarios
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.
Possible Cause Group does not have service=ppp AVP assigned. See Table 6-9.
Action Complete troubleshooting steps to isolate and resolve this possible cause.
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=ppp111803: Feb 3 20:48:53.015 CST: As2 AAA/AUTHOR/LCP (153050196): send AV protocol=lcp111804: 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_tac111807: Feb 3 20:48:53.015 CST: AAA/AUTHOR/TAC+: (153050196): send AV service=ppp111808: Feb 3 20:48:53.015 CST: AAA/AUTHOR/TAC+: (153050196): send AV protocol=lcp111809: Feb 3 20:48:53.219 CST: As2 AAA/AUTHOR (153050196): Post authorization status = FAIL111810: 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:
Step 3 Add service=ppp and related AVPs protocol=ip and protocol=lcp.
6-33Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.4 Troubleshooting Scenarios
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.
Possible Cause AVPs not assigned. See Table 6-10.
Action Complete troubleshooting steps to isolate and resolve this possible cause.
Step 1 Review the group profile. In this case, the group profile shows inacl=110 is assigned to the aaa_test_group profile:
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.
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 = 0Feb 3 21:18:05 coachella profile_cycle = 12Feb 3 21:18:05 coachella }
Step 4 Add aaa authorization network default group tacacs+ global command to the NAS configuration.
6-34Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.4 Troubleshooting Scenarios
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.
Possible Cause User or group does not have service=shell AVP assigned. See Table 6-16.
Action Complete troubleshooting steps to isolate and resolve this possible cause.
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=EXEC092738: 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_tac092740: 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:
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.
Possible Cause User or group does not have correct PPP reply attributes. See Table 6-9.
Action Complete troubleshooting steps to isolate and resolve this possible cause.
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>
6-36Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.4 Troubleshooting Scenarios
However, the csuslog file also shows that the authorization failed service for user dial_tac because the service=shell AVP is not assigned:
User Profile Informationuser = rad_dial{profile_id = 23set server current-failed-logins = 0profile_cycle = 4password = pap "********"radius=Cisco {reply_attributes= {7=19,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).
6-37Cisco AAA Implementation Case Study
Chapter 6 Diagnosing and Troubleshooting AAA Operations6.4 Troubleshooting Scenarios
6-38Cisco AAA Implementation Case Study
Cis
A P P E N D I X A
AAA Device Configuration Listings
This appendix provides the following configuration listings:
• A.1.1 Example Local-Based Router AAA Configuration
• A.1.2 Example Server-Based TACACS+ NAS Configuration
• A.1.3 Example Server-Based RADIUS NAS Configuration
• A.4.1 CSU.cfg Listing
• A.4.2 CSConfig.ini Listing
• A.4.3 Oracle User Environment Variable
• A.4.4 listener.ora Listing
A.1 Sample Cisco IOS Configuration ListingsThe following listing represents the complete running configuration for the router and NAS used to illustrate AAA implementation in this solution guide. Listings are included for TACACS+ and RADIUS configurations.
A.1.1 Example Local-Based Router AAA ConfigurationThe following example of a local-based router configuration includes both dial-in and EXEC shell access configurations.
maui-rtr-03#show running-configBuilding configuration... Current configuration:!! Last configuration change at 09:19:35 CST Thu Apr 13 2000 by brownr! NVRAM config last updated at 09:14:55 CST Thu Apr 13 2000 by brownr!version 12.0service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezoneservice password-encryption!hostname maui-rtr-03!no logging consoleaaa new-modelaaa authentication login default local enableaaa authentication login NO_AUTHEN noneaaa authorization exec default localaaa authorization exec NO_AUTHOR noneaaa authorization commands 15 default localaaa authorization commands 15 NO_AUTHOR noneaaa accounting exec default start-stop group tacacs+aaa accounting commands 15 default stop-only group tacacs+enable secret 5 xxxxxxxxxxxxxxxxx!username admin privilege 15 password 7 xxxxxxxxxxxx!!!clock timezone cst -6clock summer-time CST recurringip subnet-zeroip domain-name maui-onions.comip name-server x.x.x.xip name-server x.x.x.x!!!!!!!interface Loopback0 ip address 172.22.255.3 255.255.255.255 no ip directed-broadcast!interface ATM1/0 no ip address no ip directed-broadcast shutdown no atm ilmi-keepalive!interface Serial2/0 ip address 10.10.10.1 255.255.255.0 no ip directed-broadcast!
interface Serial2/1 no ip address no ip directed-broadcast shutdown!interface Serial2/2 no ip address no ip directed-broadcast shutdown!interface Serial2/3 no ip address no ip directed-broadcast shutdown!interface Ethernet3/0 ip address 172.22.241.3 255.255.255.0 no ip directed-broadcast ip summary-address eigrp 69 172.22.80.0 255.255.240.0 5!interface Ethernet3/1 no ip address no ip directed-broadcast shutdown!interface Ethernet3/2 no ip address no ip directed-broadcast shutdown!interface Ethernet3/3 no ip address no ip directed-broadcast shutdown!interface FastEthernet4/0 ip address 172.22.80.1 255.255.255.0 no ip directed-broadcast ip summary-address eigrp 69 172.22.240.0 255.255.240.0 5 half-duplex!router eigrp 69 network 172.22.0.0!ip default-gateway 172.22.53.1ip classlessip http serverip http authentication aaaip tacacs source-interface Loopback0!snmp-server engineID local 00000009020000D0BB7F5054snmp-server community cisco xxsnmp-server community rules xxsnmp-server trap-source Loopback0snmp-server contact snmp-server enable traps isdn call-informationsnmp-server enable traps isdn layer2snmp-server enable traps configsnmp-server enable traps envmontacacs-server host 172.22.53.201 key bitemetacacs-server key ciscorules!line con 0 authorization commands 15 NO_AUTHOR
A.1.2 Example Server-Based TACACS+ NAS ConfigurationThe following example of a server-based NAS configuration includes both dial-in and EXEC shell access configurations for TACACS+ implementations:
framing esf clock source line primary linecode b8zs pri-group timeslots 1-24!controller T1 1 clock source line secondary 1!controller T1 2 clock source line secondary 2!controller T1 3 clock source line secondary 3!controller T1 4 clock source line secondary 4!controller T1 5 clock source line secondary 5!controller T1 6 clock source line secondary 6!controller T1 7 clock source line secondary 7!!interface Loopback0 ip address 172.22.87.3 255.255.255.255 no ip directed-broadcast no ip route-cache no ip mroute-cache!interface Loopback1 ip address 172.22.83.1 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache!interface Ethernet0 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache shutdown!interface Serial0 no ip address no ip directed-broadcast encapsulation ppp no ip route-cache no ip mroute-cache shutdown no fair-queue clockrate 2015232!interface Serial1 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache shutdown no fair-queue clockrate 2015232
!interface Serial2 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache shutdown no fair-queue clockrate 2015232!interface Serial3 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache shutdown no fair-queue clockrate 2015232!interface Serial0:23 description "PRI D channel" ip unnumbered Dialer1 no ip directed-broadcast encapsulation ppp no ip route-cache no logging event link-status timeout absolute 240 0 dialer rotary-group 1 dialer-group 5 no snmp trap link-status isdn switch-type primary-5ess isdn incoming-voice modem no fair-queue compress stac no cdp enable!interface FastEthernet0 ip address 172.22.80.3 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache duplex auto speed auto!interface Group-Async1 ip unnumbered Loopback0 no ip directed-broadcast encapsulation ppp no ip route-cache ip tcp header-compression passive no ip mroute-cache no logging event link-status dialer in-band dialer idle-timeout 900 async mode interactive no snmp trap link-status peer default ip address pool default no fair-queue no cdp enable ppp max-bad-auth 3 ppp authentication pap chap group-range 1 192!interface Dialer1
no ip address no ip directed-broadcast encapsulation ppp no ip route-cache no ip mroute-cache no logging event link-statustimeout absolute 240 0 dialer in-band dialer idle-timeout 300 either dialer-group 5 no snmp trap link-status peer default ip address pool default no fair-queue compress stac no cdp enable ppp max-bad-auth 3 ppp multilink!router eigrp 69 network 172.22.0.0!ip local pool default 172.22.83.2 172.22.83.254ip default-gateway 172.22.80.1ip classlessip tacacs source-interface Loopback0ip http server!access-list 110 deny tcp any any eq telnetaccess-list 110 permit tcp any anytacacs-server host 172.22.53.204tacacs-server key ciscorulessnmp-server engineID local 0000000902000050546B87BCsnmp-server community xxxxxxxxx ROsnmp-server community xxxxxxxxx RWradius-server host 172.22.53.204 auth-port 1645 acct-port 1646 key ciscorulesbanner login ^CCWelcome to maui-nas-03Maui-onions Lab Learning Rack ISG^C!line con 0 authorization commands 15 NO_AUTHOR authorization exec NO_AUTHOR login authentication NO_AUTHEN transport input noneline 1 192 session-timeout 15 exec-timeout 48 0 autoselect during-login autoselect ppp absolute-timeout 240 script dialer cisco_default refuse-message ^CCCCCCCC!!! All lines are busy, try again later ###^C modem InOut modem autoconfigure type mica transport preferred telnet transport input all transport output pad telnet rlogin udptnline aux 0line vty 0 4!end
A.1.3 Example Server-Based RADIUS NAS ConfigurationThe following example of a server-based NAS configuration includes both dial-in and EXEC shell access configurations for RADIUS implementations:
linecode b8zs pri-group timeslots 1-24!controller T1 1 clock source line secondary 1!controller T1 2 clock source line secondary 2!controller T1 3 clock source line secondary 3!controller T1 4 clock source line secondary 4!controller T1 5 clock source line secondary 5!controller T1 6 clock source line secondary 6!controller T1 7 clock source line secondary 7!!interface Loopback0 ip address 172.22.87.3 255.255.255.255 no ip directed-broadcast no ip route-cache no ip mroute-cache!interface Loopback1 ip address 172.22.83.1 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache!interface Ethernet0 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache shutdown!interface Serial0 no ip address no ip directed-broadcast encapsulation ppp no ip route-cache no ip mroute-cache shutdown no fair-queue clockrate 2015232!interface Serial1 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache shutdown no fair-queue clockrate 2015232!interface Serial2
no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache shutdown no fair-queue clockrate 2015232!interface Serial3 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache shutdown no fair-queue clockrate 2015232!interface Serial0:23 description "PRI D channel" ip unnumbered Dialer1 no ip directed-broadcast encapsulation ppp no ip route-cache no logging event link-status timeout absolute 240 0 dialer rotary-group 1 dialer-group 5 no snmp trap link-status isdn switch-type primary-5ess isdn incoming-voice modem no fair-queue compress stac no cdp enable!interface FastEthernet0 ip address 172.22.80.3 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache duplex auto speed auto!interface Group-Async1 ip unnumbered Loopback0 no ip directed-broadcast encapsulation ppp no ip route-cache ip tcp header-compression passive no ip mroute-cache no logging event link-status dialer in-band dialer idle-timeout 900 async mode interactive no snmp trap link-status peer default ip address pool default no fair-queue no cdp enable ppp max-bad-auth 3 ppp authentication pap chap group-range 1 192!interface Dialer1 no ip address no ip directed-broadcast
A.2 Router AAA Command Implementation DescriptionsConfigurations addressed in this section focus on router administration configurations. Router administration configurations cause functions to run within the router shell. Examples include commands executed from a the router console, commands executed with a VTY connection, and a shell-initiated session established using a modem. Each is an example of an EXEC function. Table A-1 provides commands relevant for a router in a Cisco IOS AAA environment.
A.3 NAS AAA Command Implementation DescriptionsConfigurations addressed in this section focus on AAA with PPP. These configurations differ from router administration configurations. PPP is a network level function and is separate from router shell functions. You can configure PPP to be initiated automatically or you can initiate PPP with a terminal window after dialing in to a NAS. Table A-2 lists commands relevant for a NAS providing PPP access a Cisco IOS AAA environment.
Note The following table lists Cisco IOS configuration commands required to support both TACACS+ and RADIUS AAA implementations.
Table A-1 Cisco IOS Commands Required to Set AAA for a Router
Cisco IOS Command Description/Application Commenttacacs-server key secret-key Specifies encryption key; must be the same in AAA server.
aaa new-model Enables AAA. Forces an implicit login authentication default against all lines/console interfaces and an implicit ppp authentication pap default against all PPP interfaces.
aaa authentication login default group tacacs+
Causes router to forward all login requests to AAA server.
aaa authorization exec default group tacacs+ if-authenticated
Use default list for authorization to verify service=shell attribute is assigned to user and download appropriate shell attributes assigned in AAA server.
aaa authorization commands 15 default group tacacs+ if-authenticated
Use command authorization for privilege level 15 commands that must be assigned to router users for successful operation of these commands.
aaa accounting exec default start-stop group tacacs+
Logs EXEC shell information for user profile in start-stop TACACS+ format.
aaa accounting commands 15 default stop-only group tacacs+
Sends TACACS+ accounting stop record at the end of a privilege level 15 command.
aaa accounting system default stop-only group tacacs+
Performs accounting for all system level events not associated with users, such as reloads in stop-start TACACS+ format.
ip tacacs source-interface FastEthernet0/0/0 Specifies this interface IP address for management in the AAA server.
ip http server Enables HTTP server access.
ip http authentication aaa Forces AAA authentication and authorization at privilege level 15.
Appendix A AAA Device Configuration ListingsA.3 NAS AAA Command Implementation Descriptions
Table A-2 Cisco IOS Commands Used to Set AAA with PPP for NAS (RADIUS and TACACS+)
IOS Command Description/Application Commentaaa new-model Enables authentication, authorization, and accounting. Forces an
implicit login authentication default against all lines/console interfaces and an implicit ppp authentication pap default against all ppp interfaces.
aaa authentication login default group tacacs+
Causes router to forward all login requests to a TACACS+ server.
aaa authentication login default group radius Causes router to forward all login requests to a RADIUS server.
aaa authentication ppp default if-needed group radius
Use default list for PPP authentication; the if-needed keyword allows clients using “Terminal Window after Dial” option to successfully authenticate to RADIUS server and negotiate PPP, without using Windows dialup networking username and password combination.
aaa authentication ppp default if-needed group tacacs+
Use default list for PPP authentication; the if-needed keyword allows clients using “Terminal Window after Dial” option to successfully authenticate to TACACS+ server and negotiate PPP, without using Windows dialup networking username and password combination.
aaa authorization exec default group radius if-authenticated
Use default list to verify authorization.
aaa authorization exec default group tacacs+ if-authenticated
Use default list for authorization to verify service=shell attribute is assigned to user and download appropriate shell attributes assigned in AAA server.
aaa authorization network default group tacacs+ if-authenticated
Use default list for authorization to verify service=-ppp attribute is assigned to user or group and download appropriate PPP attributes assigned in AAA server. Command specifies that authorization is only permitted if user or group is properly authenticated through TACACS+.
aaa authorization network default group radius if-authenticated
Use default list for authorization to verify Service-Type=Framed attribute is assigned to user or group and download appropriate PPP attributes assigned in AAA server. Command specifies that authorization is only permitted if user or group is properly authenticated through RADIUS.
aaa accounting exec default start-stop group tacacs+
Logs EXEC shell information for user profile in start-stop TACACS+ format.
aaa accounting network default start-stop group tacacs+
Logs all network related services requests, such as PPP in stop-start TACACS+ format.
aaa accounting exec default start-stop group radius
Logs EXEC shell information for user profile in start-stop RADIUS format.
aaa accounting network default start-stop group radius
Logs all network related services requests, such as PPP in stop-start RADIUS format.
A-14Cisco AAA Implementation Case Study
Appendix A AAA Device Configuration ListingsA.4 CiscoSecure for UNIX Configuration Listings
A.4 CiscoSecure for UNIX Configuration ListingsThis section provides the following listings:
• A.4.1 CSU.cfg Listing
• A.4.2 CSConfig.ini Listing
• A.4.4 listener.ora Listing
• A.4.3 Oracle User Environment Variable
For a complete description of AAA server files, go to:
Appendix A AAA Device Configuration ListingsA.4 CiscoSecure for UNIX Configuration Listings
A.4.2 CSConfig.ini Listing##cat CSConfig.ini############################################################## $Archive: $## (C) Copyright 1996 Cisco Systems. All rights reserved.## This is CiscoSecure DBServer main initialization file.## $Log: $## $NoKeyWords: $#############################################################;<--------------------- Ruler Line -------------------------------------------->; 1 2 3 4 5 6 7 8;2345678901234567890123456789012345678901234567890123456789012345678901234567890;;-------------------------------------------------------------------------------[System]; Location where the system is installedRootDir=/opt/ciscosecure ; Location of the default profile (default= $RootDir/config/DefaultProfile)DefaultProfile=/opt/ciscosecure/config/DefaultProfile ;-------------------------------------------------------------------------------[System Error]SysErrorFileDir = /opt/ciscosecure/logfiles; DBServer gets the default path for System error handler here; if it was not specified at command line with option; [-LOGPATH path] when starting the DBServer deamon.; DBServer must have sufficient access privilege to create this: path and the log file if it does not already exist. ; log levels are 1 thru 10 where Minor=1, Moderate=5, Severe=8, Catastrophic=10; (note: Catastrophic errors will shutdown the daemon)MinLogLevel = 8 ;-------------------------------------------------------------------------------[SessionMgr]; Session Manager configurables, purge interval is in minutesMaxSessions=1000PurgeInterval=60 ;-------------------------------------------------------------------------------[AccountingMgr] ;If this parameter=enable then log acct packets into cs_accounting_log databasetableLogRawAccountingPacketToDB = enable ;If we are logging accounting records then this parameter decides whether to buffer the records; in memory and then save them to the database using a background process. Enabling this will; increase burst authentication performance.;If enabled the DBServer will create enough buffers to match the value of 2 less than; the number of database connections available.
A-19Cisco AAA Implementation Case Study
Appendix A AAA Device Configuration ListingsA.4 CiscoSecure for UNIX Configuration Listings
; NOTE: There is a risk of losing records that are in memory in the event of the DBServer going; down ungracefully.BufferAccountingPackets = enable ;This parameter decides the size of each accounting packet buffer. Legal valuesare from 5 to 1000AccountingBufferSize = 500 ; if parameter=enable then dbserver will process user max session info and savein memory,; if disabled then ArchiveMaxSessionInfoToDB will also be disabled.ProcessInMemoryMaxSessionInfo = enable ; If this parameter=enable then log user max session info into cs_user_accounting database table; Note that if the BufferAccountingPackets parameter is enabled AND ProcessInMemoryMaxSessionInfo; is enabled then max session info records will be buffered as well.ArchiveMaxSessionInfoToDB = enable ; This is how often (in minutes) the system checks for accounting sessions to; purge.; NOTE: The purge interval is actually dependant upon a system background task; that is not guaranteed to run more frequently than 60 minutes. This; value is therefore not accurate to the minute and should not be set to; less than 60.AcctPurgeInterval=60 ; This is how long (in minutes) a session can be considered; active before it is purged.; NOTE: This value is dependent on the AcctPurgeInterval setting and is not; accurate to the minute. It is not intended to be set to less than 60.AcctPurgeTimeOut=1440 ;-------------------------------------------------------------------------------[DBServer]DBServerName = CSdbServerProtocol=TCPMaxPacketSize = 4096 ; Each DBServer process should have it's own unique name.; Do not put the hostname here in case more than one instance; of the DBServer is running on the same machine ;The following is for internal use only by the DBServer;Date format expected from the client application such as the GUI,;to be used for parsing date/time string. The dbserver will reject;inputs that contains other date/time format. This format will also;be used to return date/time strings.;Examples, "d MMM yyyy" => "12 Feb 1997", "EEE MMM d hh:mm:ss z yyyy" => "Tue Apr 1 09:26:55 PST 1997"DateFormat = "d MMM yyyy"DateTimeFormat = "EEE MMM d hh:mm:ss z yyyy" ;-------------------------------------------------------------------------------[ValidClients]100 = sleddog; Add list of trusted clients above ^^^^ in the format:; ClientID = Client's Host Name; CGI stub's clientID=100, and it's host name; For example 100 = localhost or 100 = 192.92.182.2; 101 = 192.92.190.5;
A-20Cisco AAA Implementation Case Study
Appendix A AAA Device Configuration ListingsA.4 CiscoSecure for UNIX Configuration Listings
;if ValidateClients=true, then we only allow the clients with ids listed;above to connect to the dbserverValidateClients = false;if FastAdminValidateClients = true, then we only allow the clients with ids;listed below to connect to the FastAdminFastAdminValidateClients = false ;-------------------------------------------------------------------------------[Protocol TCP]HostName = sleddogPort = 9900; Name of host server ; Daemon port number;Port=5001 ;-------------------------------------------------------------------------------[Workers Pool]; Maximum numbers of connection workers in pool, beyond which; newly added workers will be ignored (or deleted).MaxInPool=50 ;-------------------------------------------------------------------------------[Database]DataSource = ORACLEDriverType = JDBC-Weblogic-Oracle; Specify the rdbms installed and the driver type; (ODBC or JDBC) that interfaces with the rdbms.; Driver=ODBC or Driver=JDBC, then go to the [ODBC]; or [JDBC] section to fill in the URL info. # Oracle with ODBC;DataSource = ORACLE;DriverType = ODBC-Visigenic-Oracle # Oracle with JDBC;DataSource = ORACLE;DriverType = JDBC-Weblogic-Oracle # SQLAnywhere with ODBC;DataSource = SQLAnywhere;DriverType = ODBC-SQLAnywhere # Sybase with ODBC;DataSource = SYBASE;DriverType = ODBC-Visigenic-Sybase # Sybase with JDBC;DataSource = SYBASE;DriverType = JDBC-Weblogic-Sybase # Test with some other DB that we did not qualify;DataSource = OtherDB;DriverType = ODBC-Visigenic # names of data dictionaryProfileAttr = cs_profile_attr_dictProfileCol = cs_profile_col_dictUserAcct = cs_user_account_attr_dict ;-------------------------------------------------------------------------------[SQLAnywhere];this is the bundle databaseConnectionLicense = 12
A-21Cisco AAA Implementation Case Study
Appendix A AAA Device Configuration ListingsA.4 CiscoSecure for UNIX Configuration Listings
Username = DBAPassword = SQL ;-------------------------------------------------------------------------------[OtherDB];number of open connections allowed to the data source(based on db license)ConnectionLicense = 1Username = csecurePassword = csecure ;-------------------------------------------------------------------------------[ORACLE];number of open connections allowed to the data source(based on db license)ConnectionLicense=4Username = csecurePassword = csecure ;-------------------------------------------------------------------------------[SYBASE];number of open connections allowed to the data source(based on db license)ConnectionLicense = 8Username = csecurePassword = csecure ;-------------------------------------------------------------------------------[ODBC-SQLAnywhere];ODBC driver informationManager = sun.jdbc.odbc.JdbcOdbcDriverDriver = jdbc:odbc:SQLAnywhere;ENG=csecure;DBF=<database_file>;Start="dbeng50 -ud";Property below is required for internal use only: connection usage propertyPrepareStatement = 0 ;-------------------------------------------------------------------------------[ODBC-Visigenic-Oracle];ODBC driver informationManager = sun.jdbc.odbc.JdbcOdbcDriverDriver = jdbc:odbc:Oracle;Property below is required for internal use only: connection usage propertyPrepareStatement = 1 ;-------------------------------------------------------------------------------[ODBC-Visigenic-Sybase];ODBC driver informationManager = sun.jdbc.odbc.JdbcOdbcDriverDriver = jdbc:odbc:SybaseDBLib;Property below is required for internal use only: connection usage propertyPrepareStatement = 1 ;-------------------------------------------------------------------------------[JDBC-Weblogic-Oracle];JDBC driver informationManager=cisco.ciscosecure.dbserver.jdbc.WeblogicOciDriverManagerDriver=jdbc:weblogic:oracle:ciscosj;Property below is required for internal use only: connection usage propertyPrepareStatement = 1 ;-------------------------------------------------------------------------------[JDBC-Weblogic-Sybase];JDBC driver informationManager=cisco.ciscosecure.dbserver.jdbc.WeblogicDBLibDriverManagerDriver=jdbc:weblogic:sybase;Property below is required for internal use only: connection usage propertyPrepareStatement = 1
A-22Cisco AAA Implementation Case Study
Appendix A AAA Device Configuration ListingsA.4 CiscoSecure for UNIX Configuration Listings
;-------------------------------------------------------------------------------[ProfileCaching]EnableProfileCaching = OFF;Polling period in minutes for cs_trans_log table; Interval in seconds can be specified by fraction.; For example, '5/60' denotes 5 seconds and '1 1/2' denotes 90 seconds.; Setting to 0 disbles polling.DBPollInterval = 30;-------------------------------------------------------------------------------
A.4.3 Oracle User Environment Variable#su - oracleSun Microsystems Inc. SunOS 5.5.1 Generic May 1996$envHOME=/export/home/oracleHZ=100LD_LIBRARY_PATH=/opt/oracle/product/7.3.4/lib:/usr/openwin/lib:/usr/dt/lib:/usr/libLOGNAME=oracleORACLE_DOC=/docORACLE_HOME=/opt/oracle/product/7.3.4ORACLE_SID=ciscosjORACLE_TERM=xsun5ORAENV_ASK=NOPATH=/usr/bin::/opt/oracle/product/7.3.4:/opt/oracle/product/7.3.4/bin:/usr/ccs/bin:SHELL=/bin/shTERM=ansiTMPDIR=/var/tmpTNS_ADMIN=/opt/oracle/product/7.3.4/network/adminTZ=GMT-8
A-23Cisco AAA Implementation Case Study
Appendix A AAA Device Configuration ListingsA.4 CiscoSecure for UNIX Configuration Listings
Appendix A AAA Device Configuration ListingsA.5 CiscoSecure Log Files
A-26Cisco AAA Implementation Case Study
Cis
A P P E N D I X B
AAA Impact on Maintenance Tasks
Most BootFlash images do not recognize all Cisco IOS aaa commands. As a result, invoking a BootFlash image can lead to a password recovery situation unless the Cisco IOS fragments listed in this appendix are used to disable AAA. One example of a situation requiring the inclusion of this configuration is a software image upgrade for a Cisco AS5200 access server.
Include the following Cisco IOS commands to disable AAA authentication and authorization on the console and VTY ports of a NAS:
Diagnostic examples present captured output from debug command (router) and tail command (AAA server) listings.
Note Output fragments provided here are excerpted from the applicable debug command output or AAA server csuslog file—unless otherwise noted. Diagnostic content is gathered from the AAA server by using the tail -f /var/log/csuslog command. Pertinent portions of output are included as fragments of complete listings.
C.1 Server-Based TACACS+ Dialup Authentication DiagnosticsThe following test results for “4.1 Implementing Server-Based TACACS+ Dialup Authentication” provide relevant NAS and AAA server log output:
1. Authentication login is successful for user tac_dial.
2. PAP authentication request for user tac_dial.
3. Creation of user tac_dial, service=ppp.
4. Authentication PASS received from AAA server.
Note Use these debug commands: debug aaa authentication and debug ppp authentication.
The following diagnostic results are presented in the order in which they are generated during the authentication process. Specific output fragments are differentiated with brief explanatory notes to help you identify relevant information.
Note The debug command output can vary depending on Cisco IOS versions.
1. Authentication login is successful for user tac_dial.
113296: Feb 4 10:40:13.696 CST: AAA/AUTHEN/START (2368549471): using "default" list113297: Feb 4 10:40:13.696 CST: AAA/AUTHEN (2368549471): status = UNKNOWN113298: Feb 4 10:40:13.696 CST: AAA/AUTHEN/START (2368549471): Method=tacacs+ (tacacs+)113299: Feb 4 10:40:13.696 CST: TAC+: send AUTHEN/START packet ver=193 id=2368549471113300: Feb 4 10:40:13.900 CST: TAC+: ver=193 id=2368549471 received AUTHEN status = PASS
C.2 Server-Based TACACS+ Dialup Authorization DiagnosticsThe following test results for “4.2 Implementing Server-Based TACACS+ Dialup Authorization” provide relevant NAS and AAA server log output:
1. User dialtest is authorized EXEC shell access to the NAS.
2. User dialtest starts PPP from the shell and is assigned the addr-pool=default and inacl=110 AVPs.
3. User dialtest is authorized EXEC shell access to NAS.
4. User dialtest is assigned the addr-pool=default AVP through network authorization.
5. User dialtest is assigned the inacl=110 AVP through network authorization.
6. User dialtest starts PPP and is assigned the addr-pool=default and inacl=110 AVPs.
Note Use this debug command: debug aaa authorization.
The following diagnostic results are presented in the order in which they are generated during the authorization process. Specific output fragments are differentiated with brief explanatory notes to help you identify relevant information.
Note The debug command output can vary depending on Cisco IOS versions.
1. User dialtest is authorized EXEC shell access to the NAS.
4. User dialtest is assigned the addr-pool=default AVP through network authorization.
NAS debug output:
*Apr 6 00:12:31.480: AAA/AUTHOR/PPP: As8 (1961228100) user='dialtest'*Apr 6 00:12:31.480: As8 AAA/AUTHOR/PPP (1961228100): send AV service=ppp*Apr 6 00:12:31.480: As8 AAA/AUTHOR/PPP (1961228100): send AV protocol=ip*Apr 6 00:12:31.480: As8 AAA/AUTHOR/PPP (1961228100): send AV addr-pool*default*Apr 6 00:12:31.480: As8 AAA/AUTHOR/PPP (1961228100): found list "default"*Apr 6 00:12:31.480: As8 AAA/AUTHOR/PPP (1961228100): Method=tacacs+ (tacacs+)*Apr 6 00:12:31.480: AAA/AUTHOR/TAC+: (1961228100): user=dialtest*Apr 6 00:12:31.480: AAA/AUTHOR/TAC+: (1961228100): send AV service=ppp*Apr 6 00:12:31.480: AAA/AUTHOR/TAC+: (1961228100): send AV protocol=ip*Apr 6 00:12:31.480: AAA/AUTHOR/TAC+: (1961228100): send AV addr-pool*default*Apr 6 00:12:31.684: As8 AAA/AUTHOR (1961228100): Post authorization status = PASS_ADD
5. User dialtest is assigned the inacl=110 AVP through network authorization.
NAS debug output:
*Apr 6 00:12:31.684: AAA/AUTHOR/Async8: PPP: Processing AV service=ppp*Apr 6 00:12:31.684: AAA/AUTHOR/Async8: PPP: Processing AV protocol=ip*Apr 6 00:12:31.684: AAA/AUTHOR/Async8: PPP: Processing AV addr-pool*default*Apr 6 00:12:31.684: AAA/AUTHOR/Async8: PPP: Processing AV inacl=110
6. User dialtest starts PPP and is assigned the addr-pool=default and inacl=110 AVPs.
NAS debug output:
*Apr 6 00:33:05.860: As9 AAA/AUTHOR/IPCP: Says use pool default*Apr 6 00:33:05.864: As9 AAA/AUTHOR/IPCP: Pool returned 172.23.25.37*Apr 6 00:33:05.864: As9 AAA/AUTHOR/IPCP: Processing AV service=ppp*Apr 6 00:33:05.864: As9 AAA/AUTHOR/IPCP: Processing AV protocol=ip*Apr 6 00:33:05.864: As9 AAA/AUTHOR/IPCP: Processing AV addr-pool=default*Apr 6 00:33:05.864: As9 AAA/AUTHOR/IPCP: Processing AV inacl=110*Apr 6 00:33:05.864: As9 AAA/AUTHOR/IPCP: Processing AV addr*172.23.25.37*Apr 6 00:33:05.864: As9 AAA/AUTHOR/IPCP: Authorization succeeded
C.3 Server-Based RADIUS Dialup Authentication DiagnosticsThe following test results for “4.3 Implementing Server-Based RADIUS Dialup Authentication” provide relevant NAS output:
1. User rad_dial successfully passes authentication on port Async 5).
2. User rad_dial successfully passes authentication.
Note Use these debug commands: debug aaa authentication and debug ppp authentication.
The following diagnostic results are presented in the order in which they are generated during the authentication process. Specific output fragments are differentiated with brief explanatory notes to help identify relevant information.
2. User rad_dial successfully passes authentication.
NAS debug output:
Apr 6 16:18:19 danvers CiscoSecure: INFO - Profile: user = rad_dial {Apr 6 16:18:19 danvers set server current-failed-logins = 0Apr 6 16:18:19 danvers profile_cycle = 9
C.4 Server-Based RADIUS Dialup Authorization DiagnosticsThe following test results for “4.4 Implementing Server-Based RADIUS Dialup Authorization” provide relevant NAS server log output:
1. User rad_dial is authorized for protocol=lcp.
2. User rad_dial is authorized for IPCP.
3. Input access-list is verified as 110 while the output access-list is shown as not set.
Note Use these commands: debug aaa authorization and show caller user rad_dial detail.
The following diagnostic results are presented in the order in which they are generated during the authorization process. Specific output fragments are differentiated with brief explanatory notes to you identify relevant information.
Output from show caller user rad_dial detail from NAS:
User: rad_dial, line tty 116, service Async Active time 00:01:29, Idle time 00:00:40 Timeouts: Absolute Idle Idle Session Exec Limits: 04:00:00 - 00:48:00 Disconnect in: 03:58:30 - - TTY: Line 116, running PPP on As116 Location: PPP: 172.22.83.37 DS0: (slot/unit/channel)=0/0/20 Line: Baud rate (TX/RX) is 115200/115200, no parity, 1 stopbits, 8 databits Status: Ready, Active, No Exit Banner, Async Interface Active HW PPP Support Active, Modem Detected Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out Modem Callout, Modem RI is CD, Line usable as async interface, Modem Autoconfigure Integrated Modem Modem State: Ready, Modem Configured
User: rad_dial, line As116, service PPP Active time 00:01:23, Idle time 00:00:35 Timeouts: Absolute Idle Limits: - - Disconnect in: - - PPP: LCP Open, PAP (<- AAA), IPCP, CDPCP LCP: -> peer, ACCM, AuthProto, MagicNumber, PCompression, ACCompression <- peer, ACCM, MagicNumber, PCompression, ACCompression NCP: Open IPCP, CDPCP IPCP: <- peer, Address -> peer, Address IP: Local 172.22.83.1, remote 172.22.83.37 Access list (I/O) is 110/not set, default (I/O) not set/not set Counts: 14 packets input, 1399 bytes, 0 no buffer 1 input errors, 1 CRC, 0 frame, 0 overrun 15 packets output, 1448 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets
C.5 Server-Based TACACS+ Router Authentication DiagnosticsThe following test results for “4.5 Implementing Server-Based TACACS+ Router Authentication” provide relevant router output:
1. Get user and password interaction between router and AAA server.
2. User rtr_test successfully logs in.
Note Use this debug command: debug aaa authentication.
The following diagnostic results are presented in the order in which they are generated during the authentication process. Specific output fragments are differentiated with brief explanatory notes to you identify relevant information.
Note The debug command output can vary depending on Cisco IOS versions.
1. Get user and password interaction between router and AAA server.
C.6 Server-Based TACACS+ Router Authorization DiagnosticsThe following test results illustrate three separate user types as described in “4.6 Implementing Server-Based TACACS+ Router Authorization”, belonging to three separate user groups: rtr_low, rtr_tech, and rtr_super. The example output is provided in the following sections:
• C.6.1 Test Results for rtr_low Group
• C.6.2 Test Results for rtr_tech Group
• C.6.3 Test Results for rtr_super Group
Note Use this debug command: debug aaa authorization.
C.6.1 Test Results for rtr_low GroupTest results follow for each Cisco IOS command summarized in Table 4-1, including relevant router output and AAA server log output:
1. User rtr_dweeb is authorized EXEC shell access.
2. User rtr_dweeb enters enable mode.
3. User rtr_dweeb fails debug all command.
4. User rtr_dweeb fails debug ip packet command.
5. User rtr_dweeb fails clear ip cache command.
6. User rtr_dweeb fails reload command.
7. User rtr_dweeb fails show running-config command.
8. User rtr_dweeb fails write terminal command.
9. User rtr_dweeb fails copy running-config startup-config command.
10. User rtr_dweeb fails write memory command.
11. User rtr_dweeb fails configure terminal command.
The following diagnostic results are presented in the order in which they are generated during the authorization process. Specific output fragments are differentiated with brief explanatory notes to help you identify relevant information.
C.6.2 Test Results for rtr_tech GroupTests results follow for each of the Cisco IOS commands summarized in Table 4-1, including relevant router output and AAA server log output:
1. User rtr_techie is authorized EXEC shell access.
2. User rtr_techie enters enable mode.
3. User rtr_techie is denied the debug all command.
4. User rtr_techie is permitted debug ip packet command.
5. User rtr_techie is permitted clear ip cache command.
6. User rtr_techie is denied reload command.
7. User rtr_techie is permitted show running-config command.
8. User rtr_techie is permitted write terminal command.
9. User rtr_techie is permitted copy running-config starting config command.
10. User rtr_techie is permitted write memory command.
11. User rtr_techie is denied configure terminal command.
The following diagnostic results are presented in the order in which they are generated during the authorization process. Specific output fragments are differentiated with brief explanatory notes to help you identify relevant information.
Note The debug command output can vary depending on Cisco IOS versions.
1. User rtr_techie is authorized EXEC shell access.
C.6.3 Test Results for rtr_super GroupTests results follow for each of the Cisco IOS commands summarized in Table 4-1, including relevant router output and AAA server log output:
1. User rtr_geek is authorized EXEC shell access.
2. User rtr_geek enters enable mode.
3. User rtr_geek is denied debug all command.
4. User rtr_geek is permitted debug ip packet command.
5. User rtr_geek is permitted reload command.
6. User rtr_geek is permitted show running-config command.
7. User rtr_geek is permitted write terminal command.
8. User rtr_geek is permitted copy running-config startup-config command.
9. User rtr_geek is permitted write memory command.
10. User rtr_geek is permitted configure terminal command.
The following diagnostic results are presented in the order in which they are generated during the authorization process. Specific output fragments are differentiated with brief explanatory notes to help you identify relevant information.