Share this page : facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

Server-Based AAA Authorization

While authentication must ensure that the device or end user is legitimate, authorization is concerned with allowing and disallowing authenticated users access to certain areas and programs on the network.

The TACACS+ protocol allows the separation of authentication from authorization.

Another important aspect of authorization is the ability to control user access to specific services. Controlling access to configuration commands greatly simplifies the infrastructure security in large enterprise networks. Per-user permissions on the Cisco Secure ACS simplify network device configuration.

By default, TACACS+ establishes a new TCP session for every authorization request, which can lead to delays when users enter commands. To improve performance, Cisco Secure ACS supports persistent TCP sessions configured with the single-connection tacacs server configuration mode command.

e.g:

R1(config)#tacacs server test
R1(config-server-tacacs)#single-connection
AAA Authorization Configuration

To configure command authorization, use the aaa authorization command:

R1(config)# aaa authorization (network | exec | commands level} {default | list-name} method1...{ method4}

The service type can specify the types of commands or services:

  • network – For network services such as PPP
  • exec – For starting an exec (shell);
  • commands level – For exec (shell) commands

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.

When AAA authorization is not enabled, all users are allowed full access. After authentication is started, the default changes to allow no access. This means that the administrator must create a user with full access rights before authorization is enabled.

R1(config)# aaa authorization exec default group tacacs+
R1(config)# aaa authorization network default group tacacs+

Failure to do so immediately locks the administrator out of the system the moment the aaa authorization command is entered. The only way to recover from this is to reboot the router. If this is a production router, rebooting might be unacceptable. Be sure that at least one user always has full rights.

Server-Based AAA Accounting

Companies often need to keep track of which resources individuals or groups use. AAA accounting enables usage tracking. An example of usage tracking is when one department charges another department for access, or when one company provides internal support to another company.

Although accounting is generally considered a network management or financial management issue, it is discussed briefly here because it is so closely linked with security. One security issue that is addressed by accounting is the creation of a list of users and the time of day they logged into the system. If, for example, the administrator knows that a worker logs in to the system in the middle of the night, this information can be used to further investigate the purpose of the login.

Another reason to implement accounting is to create a list of changes occurring on the network, the user that made the changes, and the exact nature of the changes. Knowing this information helps the troubleshooting process if the changes cause unexpected results.

Cisco Secure ACS serves as a central repository for accounting information. It tracks events that occur on the network.This stored information can be very helpful for management, security audits, capacity planning, and network usage billing.

AAA Accounting Configuration

To configure AAA accounting, use the aaa accounting command:

R1(config)# aaa accounting (network | exec | connection) {default | list-name} {start-stop | stop-only | none} [broadcast] method1...{ method4}

The following three parameters are commonly used aaa accounting keywords:

  • network – Runs accounting for all network-related service requests, including PPP.
  • exec – Runs accounting for the EXEC shell session.
  • connection – Runs accounting on all outbound connections such as SSH and Telnet.

As with AAA authentication, either the keyword default or a list-name can be used.

Next, the record type, or trigger, is configured. The trigger specifies what actions cause accounting records to be updated. Possible triggers include:

  • start-stop – Sends a “start” accounting notice at the beginning of a process and a “stop” accounting notice at the end of a process.
  • stop-only – Sends a “stop” accounting record for all cases including authentication failures.
  • none – Disables accounting services on a line or interface.

 

Security using 802.1x port-based authentication

The IEEE 802.1X standard defines a port-based access control and authentication protocol that restricts unauthorized workstations from connecting to a LAN through publicly accessible switch ports. The authentication server authenticates each workstation that is connected to a switch port before making available any services offered by the switch or the LAN.

port-based Authentication_device

The devices in the network have specific roles:

  • Supplicant (Client, workstations) – The device (workstation) that requests access to LAN and switch services and then responds to requests from the switch. The workstation must be running 802.1X-compliant client software. (The port that the client is attached to is the supplicant [client] in the IEEE 802.1X specification.)
  • Authenticator (Switch) – Controls physical access to the network based on the authentication status of the client. The switch acts as an intermediary (proxy) between the client (supplicant) and the authentication server, requesting identifying information from the client, verifying that information with the authentication server, and relaying a response to the client. The switch uses a RADIUS software agent, which is responsible for encapsulating and de-encapsulating the EAP (Extensible Authentication Protocol) frames and interacting with the authentication server.
  • Authentication server – Performs the actual authentication of the client. The authentication server validates the identity of the client and notifies the switch whether the client is authorized to access the LAN and switch services. Because the switch acts as the proxy, the authentication service is transparent to the client. The RADIUS security system with EAP extensions is the only supported authentication server.

Until the workstation is authenticated, 802.1X access control enables only Extensible Authentication Protocol over LAN (EAPOL) traffic through the port to which the workstation is connected. After authentication succeeds, normal traffic can pass through the port.

Switch port state:

The switch port state determines whether the client is granted access to the network. When configured for 802.1X port-based authentication, the port starts in the unauthorized state. While in this state, the port disallows all ingress and egress traffic except for 802.1X protocol packets. When a client is successfully authenticated, the port transitions to the authorized state, allowing all traffic for the client to flow normally. If the switch requests the client identity (authenticator initiation) and the client does not support 802.1X, the port remains in the unauthorized state, and the client is not granted access to the network.

In contrast, when an 802.1X-enabled client connects to a port and the client initiates the authentication process (supplicant initiation) by sending the EAPOL-start frame to a switch that is not running the 802.1X protocol, no response is received, and the client begins sending frames as if the port is in the authorized state.

802.1x Message Exchange

As shown above, Complete message exchange between the supplicant, authenticator, and the authentication server. The encapsulation occurs as follows:

  • Between the supplicant and the authenticator – EAP data is encapsulated in EAPOL frames.
  • Between the authenticator and the authentication server – EAP data is encapsulated using RADIUS.
802.1X Port Authorization State

port-based Authentication_device

  • If the client is successfully authenticated (receives an “accept” frame from the authentication server), the port state changes to authorized, and all frames from the authenticated client are enabled through the port.
  • If the authentication fails, the port remains in the unauthorized state, but authentication can be retried. If the authentication server cannot be reached, the switch can retransmit the request. If no response is received from the server after the specified number of attempts, authentication fails, and network access is not granted.
  • When a client logs out, it sends an EAPOL-logout message, causing the switch port to transition to the unauthorized state.

Use the authentication port-control command to control the port authorization state. The syntax for the command and a description:

switch(config-if)# authentication port-control { auto | force-authorized | force-unauthorized}
  • auto: Enable 802.1X port-based authentication and causes the port to begin in the unauthorized state, enabling only EAPOL frames to be sent and received through the port.
  • Force-authorized: the port sends and receives normal traffic without 802.1x-based authentication of the client, this is the default setting.
  • Force-unauthorized cases the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate. The switch can not provide authentication services to the clients through the port.

By default, a port is in the force-authorized state meaning it can send and receive traffic without 802.1x authentication.

The auto keyword must be entered to enable 802.1X authentication.

  • If the client is successfully authenticated (receives an Accept frame from the authentication server), the port state changes to authorized, and all frames from the authenticated client are allowed through the port.
  • If the authentication fails, the port remains in the unauthorized state, but authentication can be retried.
  • If the authentication server cannot be reached, the switch can resend the request.
  • If no response is received from the server after the specified number of attempts, authentication fails, and network access is not granted.

When a client logs off, it sends an EAPOL-logoff message, causing the switch port to change to the unauthorized state.

If the link state of a port changes from up to down, or if an EAPOL-logoff frame is received, the port returns to the unauthorized state

example:

802.1x

shows a scenario where a PC is attached to F0/1 on the switch and the device is getting authenticated via 802.1X with a RADIUS server.

Configuring 802.1X requires a few basic steps:

Step 1. Enable AAA using the aaa new-model command and configure the RADIUS server.

Step 2. Create an 802.1X port-based authentication method list using the aaa authentication dot1x command.

Step 3. Globally enable 802.1X port-based authentication using the dot1x system-auth-control command.

Step 4. Enable port-based authentication on the interface using the authentication port-control auto command.

Step 5. Enable 802.1X authentication on the interface using the dot1x pae command. The authenticator options sets the Port Access Entity (PAE) type so the interface acts only as an authenticator and will not respond to any messages meant for a supplicant.

https://static-course-assets.s3.amazonaws.com/CCNAS2/en/index.html#3.6.1.1