Share this page : facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
Authentication

Cisco provides two common methods of implementing AAA services:

  • Local AAA Authentication Local AAA uses a local database for authentication. This method is sometimes known as self-contained authentication. In this course, it will be referred to as local AAA authentication. This method stores usernames and passwords locally in the Cisco router, and users authenticate against the local database. This database is the same one required for establishing role-based CLI. Local AAA is ideal for small networks.
  • Server-Based AAA Authentication – With server-based method, the router accesses a central AAA server, such as the Cisco Secure Access Control System (ACS) for Windows, shown in Figure 2. The central AAA server contains the usernames and password for all users. The router uses either the Remote Authentication Dial-In User Service (RADIUS) or Terminal Access Controller Access Control System (TACACS+) protocols to communicate with the AAA server. When there are multiple routers and switches, server-based AAA is more appropriate.1. When a user has been authenticated, a session is established between the router and the AAA server.
    2. The router requests authorization from the AAA server for the client’s requested service.

Note: In this course, the focus is on implementing network security with IPv4 on Cisco routers, switches, and Adaptive Security Appliances. On occasion, references are made to IPv6-specific technologies and protocols.

Authorization

Authorization is basically what users can and cannot do on the network after they are authenticated.

Authorization is typically implemented using a AAA server-based solution. Authorization uses a created set of attributes that describes the user’s access to the network. These attributes are compared to the information contained within the AAA database, and a determination of restrictions for that user is made and delivered to the local router where the user is connected.

Authorization is automatic and does not require users to perform additional steps after authentication. Authorization is implemented immediately after the user is authenticated.

Accounting

AAA Accounting collects and reports usage data. This data can be used for such purposes as auditing or billing.

The collected data might include

  1. The start and stop connection times,
  2. executed commands,
  3. number of packets,
  4. Number of bytes.

These statistics can be extracted to create detailed reports about the configuration of the network.

Type of Accounting information:

  1. Network accounting:Network accounting captures information for all Point-to-Point Protocol (PPP) sessions, including packet and byte counts.
  2. Connection accounting: Connection accounting captures information about all outbound connections made from the AAA client, such as Telnet or SSH.
  3. EXEC accounting: EXEC accounting captures information about user EXEC terminal sessions (user shells) on the network access server, including username, date, start and stop times, and the access server IP address..
  4. System accounting: System accounting captures information about all system-level events (for example, when the system reboots or when accounting is turned on or off).
  5. Command accounting: Command accounting captures information about the EXEC shell commands for a specified privilege level that are being executed on a network access server. Each command accounting record includes a list of the commands executed for that privilege level, as well as the date and time each command was executed, and the user who executed it.
  6. Resource Accounting: The Cisco implementation of AAA accounting captures “start” and “stop” record support for calls that have passed user authentication. The additional feature of generating “stop” records for calls that fail to authenticate as part of user authentication is also supported. Such records are necessary for users employing accounting records to manage and monitor their networks.
Configure Local AAA authentication

Configuring local AAA services to authenticate administrator access requires a few basic steps:

Step 1. Add usernames and passwords to the local router database for users that need administrative access to the router.

Step 2. Enable AAA globally on the router.

Step 3. Configure AAA parameters on the router.

Step 4. Confirm and troubleshoot the AAA configuration.

eg.

R1(config)# username JR-admin algorithm-type scrypt secret [email protected]

R1(config)# username Admin algorithm-type scrypt secret [email protected]

R1(config)# aaa new-model

R1(config)# aaa authentication login default local-case

aaa authentication login {default | list-name} method1 ... [method4]

  • The aaa authentication login command in the figure allows the ADMIN and JR-ADMIN users to log into the router via the console or vty terminal lines.
  • The default keyword means that the authentication method applies to all lines, except those for which a specific line configuration overrides the default.
  • The authentication is case-sensitive, indicated by the local-case keyword. This means that both the password and the username are case sensitive.
  • list-name: character string used to name the list of authentication methods activated when a user logs in.
  • method1…[method4] : identifies the list of methods that the AAA authentication process will query in the given sequence. At least one method must be specified. A maximum of four methods may be specified,providing fallback methods should one method not be available. The Keywords types are:
    • enable: uses the enable password for authentication
    • local: uses the local username database for authentication
    • local-case: uses case-sensitive local username authentication
    • none: If no RADIUS server can be reached and authentication cannot be performed, the router globally allows access without authentication.
    • group radius : uses the list of all RADIUS servers for authentication
    • group tacacs+ : uses the list of all TACACS+ servers for authentication
    • group group-name: Users a subset of RADIUS or TACACS+ servers for authentication as defined by the aaa group server radius or aaa group server tacacs+ command.Note: the difference between the two options local and local-case is that local accepts a username regardless of case, whereas local-case is case-sensitive.”none” keyword only should be used for testing the AAA configuration, should never be applied on a live network.
  • list-name:Notice that the named list has to be explicitly enabled on the line using the login authentication line configuration command. If a line has a custom authentication method list applied to it, that method list overrides the default method list for that interface.When a custom authentication method list is applied to an interface, it is possible to return to the default method list by using the no authentication login command.
Fine-tuning the Authentication configuration

 

Set the maximum attempts a user can try before the account being locked:

r1(config)# aaa local authentication attempts max-fail number-of-unsuccessful-attempts

The locked out user account remains locked until it is manually cleared by an administrator using the clear aaa local user lockout privileged EXEC mode command.

To display a list of all locked-out users, use the show aaa local user lockout command

To display the attributes that are collected for one AAA session, use the show aaa user command in privileged EXEC mode.

The show aaa sessions command can be used to show the unique ID of a session

Troublshooting local AAA authentication

Debug aaa command contains several keywords that can be used for this purpose. Of special interest is the debug aaa authentication command.

It is important to analyze debug output when everything is working properly. Knowing how debug output displays when all is well helps identify problems when things are not working properly. Exercise caution when using any debug commands in a production environment because these commands are interpreted by the control plane; therefore, they place a significant load on router resources and can negatively affect network performance.

To disable this command, use the no debug aaa authentication command or the all-encompassing undebug all statement.

Server-based AAA

The server-based authentication has the processes:

server_based AAA

1. The user establishes a connection with the router.
2. The router prompts the user for a username and password.
3. The router passes the username and password to the Cisco Secure ACS (Access control system, server or engine).
4. The Cisco Secure ACS authenticates the user. The user is provided access to the router (administrative access) or the network, based on information found in the Cisco Secure ACS database.

Cisco Secure ACS can create a central user and administrative access database to which all devices in the network can refer. It can also work with many external databases, including Active Directory and Lightweight Directory Access Protocol (LDAP). These databases store user account information and passwords, allowing for central administration of user accounts. For increased redundancy, multiple servers can be implemented.

Introducing Cisco Secure Access Control System

The Cisco Secure Access Control System (ACS) is a centralized solution that ties together an enterprise’s network access policy and identity strategy.

The Cisco ACS family of products comprises highly scalable, high-performance access control servers. These can be leveraged to control administrator access and configuration for all network devices in a network supporting RADIUS, or TACACS+, or both.

RADIUS TACACS+
Standard Open/RFC standard Mostly Cisco supported
Packet delivery UDP. TCP.
Customization Has no option to authorize router commands on a per-user or per-group basis Provides authorization of router commands on a per-user or per-group basis
CHAP Unidirectional chanllenge and response from the RADIUS security server to the RADIUS client Bidirectional chanllenge and response as used in CHAP
Packet encryption Encrypts only the password in the access-request packet from the client to the server. Encrypts the entire packet but leaves a standard TCP header.
AAA support Combines authentication and authorization. Uses the AAA architecture, separating authentication, authorization, and accounting.
Multiprotocol support None. Supports other protocols, such as AppleTalk, NetBIOS, and IPX.
Router management Can pass a privilege level down to the router, which can then be used locally for command authorization. Enables network administrators to control which commands can be executed on a router.
Responses Uses single-challenge response. Combines authentication and authorization. Uses multiple-challenge response for each of the AAA processes. Uses the AAA architecture and separates each process.
Accounting Extensive limited

 

Differences between the TACACS+ and RADIUS protocols:

These are three critical factors for TACACS+:

  • Separates authentication and authorization
  • Encrypts all communication
  • Utilizes TCP port 49

These are four critical factors for RADIUS:

  • Combines RADIUS authentication and authorization as one process
  • Encrypts only the password
  • Utilizes UDP
  • Supports remote-access technologies, 802.1X, and Session Initiation Protocol (SIP)

While both protocols can be used to communicate between a router and AAA servers, TACACS+ is considered the more secure protocol. This is because all TACACS+ protocol exchanges are encrypted, while RADIUS only encrypts the user’s password. RADIUS does not encrypt user names, accounting information, or any other information carried in the RADIUS message.

TACACS+ Authentication

TACACS+ is a Cisco enhancement to the original TACACS protocol. Despite its name, TACACS+ is an entirely new protocol that is incompatible with any previous version of TACACS. TACACS+ is supported by the Cisco family of routers and access servers.

TACACS+ provides separate AAA services. Separating the AAA services provides flexibility in implementation because it is possible to use TACACS+ for authorization and accounting while using another method of authentication.

The extensions to the TACACS+ protocol provide more types of authentication requests and response codes than were in the original TACACS specification. TACACS+ offers multiprotocol support, such as IP and legacy AppleTalk. Normal TACACS+ operation encrypts the entire body of the packet for more secure communications and utilizes TCP port 49.

RADIUS

The RADIUS protocol hides passwords during transmission, even with the Password Authentication Protocol (PAP), using a rather complex operation that involves Message Digest 5 (MD5) hashing and a shared secret. However, the rest of the packet is sent in plaintext.

RADIUS combines authentication and authorization as one process. When a user is authenticated, that user is also authorized. RADIUS uses UDP port 1645 or 1812 for authentication and UDP port 1646 or 1813 for accounting.

RADIUS is widely used by VoIP service providers. It passes login credentials of a SIP endpoint, such as a broadband phone, to a SIP registrar using digest authentication, and then to a RADIUS server using RADIUS. RADIUS is also a common authentication protocol that is utilized by the 802.1X security standard.

Note: A next-generation AAA protocol alternative to RADIUS is the DIAMETER AAA protocol. DIAMETER is an IETF standard that uses a new transport protocol called Stream Control Transmission Protocol (SCTP) and TCP instead of UDP.

Integration of TACACS+ and ACS

Cisco Secure ACS version 5.6 is a highly sophisticated policy-based access control platform. Some features of Cisco Secure ACS include:

  • A distributed architecture for medium-sized and large-scale deployments
  • A lightweight web-based GUI with intuitive navigation, accessible from both IPv4 and IPv6 clients
  • Administrator authentication through Microsoft Active Directory and Lightweight Directory Access Protocol (LDAP)
  • Scheduled (automated) reports sent through email
  • Integrated advanced monitoring, reporting, and troubleshooting capabilities for excellent control and visibility using SNMP traps for Cisco Secure ACS health status
  • Encrypted (secure) syslogs
  • Flexible and detailed device administration in IPv4 and IPv6 networks, with full auditing and reporting capabilities as required for standards compliance.

 

Integration of AAA with Active Directory

The AD domain controller is used to enforce security policies by authenticating and authorizing users when they log into the Windows domain. Microsoft AD can also be used to handle authentication and authorization on Cisco IOS devices.

Although Cisco Secure ACS can be integrated to use the AD service, Microsoft Windows Server can also be configured as a AAA server. The Microsoft implementation of a AAA server using RADIUS is known as Internet Authentication Service (IAS). However, starting with Windows Server 2008, IAS has since been renamed Network Policy Server (NPS).

The configuration for Cisco IOS is the same as communicating with any RADIUS server. The only difference is that the Microsoft server’s AD controller is used to perform the authentication and authorization services.

3.3.2.6

Cisco ISE combines policy definition, control, and reporting in one appliance. ISE works with existing network infrastructure to provide network administrators with information about the end devices (known as endpoints) that attach to the network.

Integration of AAA with identity service Engine

There are four features in the ISE toolset:

  • Device profiling – This can be used to determine whether it is a personal or corporate device.
  • Posture assessment – Determines if the device is clean of viruses and suspicious applications before entering the network. Posture assessment can also make sure that a device’s antivirus software is up to date.
  • Guest management – Grants and enforces temporary access for guest users.
  • AAA – Combines authentication, authorization, accounting, into one appliance with device profiling, posture assessment and guest management capability.

A primary function of ISE is identity-based network access. ISE provides context-aware identity management:

  • To determine whether users are accessing the network on an authorized, policy-compliant device
  • To establish user identity, location, and access history, which can be used for compliance and reporting
  • To assign services based on the assigned user role, group, and associated policy (job role, location, device type, etc.)
  • To grant authenticated users access to specific segments of the network, or specific applications and services, or both, based on authentication results