CCNA Security 28

Before we begin, let's redefine what AAA is. AAA contains three components: Authentication, Authorization, and Accounting. Authentication is to check if the user is genuine, Authorization defines the things the user can perform, and Accounting is logging of the activity of the authenticated user.
Authentication is valid without Authorization, but Authorization is never valid without Authentication. AAA can be performed using either a LOCAL, RADIUS server or a TACACS+ server.

There are three types of authentication:
1) Console access - The ASA requires authentication before permitting console access
2) Cut-through proxy - The ASA is configured to require authentication before access is allowed through it.
3) Tunnel access - Before establishment of a full tunnel, the user has to authenticate.

We can authenticate and authorize through local databases. Through a cut-through proxy, you can configure the ASA to authenticate and authorize for both Telnet and FTP. Once a user is authenticated either for Telnet or FTP, he can use the other service without reauthenticating.

The cut-through proxy is defined with interesting traffic. This interesting traffic triggers the authentication process which communicates with the AAA server. If the AAA server is running ACS, it can upload authentication/authorization AAA lists into the appliance itself.

Before we can start, we'll configure some local accounts:
user cisco pass cisco

The local database can be used for CLI access authentication, privilege mode authentication, command authorization, network access authentication, and VPN authentication/authorization. However, the local database cannot be used for network access authorization as well as all forms of accounting.

We can configure users in the ASDM by browsing to Configuration - Local AAA - User Accounts. We can configure various things like which users are permitted, or how many retries are allowed for a single user account. If a user account gets locked out, we can unlock his account by going to Monitoring - Device Access - AAA Local Locked Out Users.

In this article, I'll discuss configuring the cut-through proxy to be used with an RADIUS server in the backend (the local database simply requires you to have an account and to designate the rule to use the LOCAL database). The topology looks like this:


How this cut-through proxy scheme works is that when the user connects to the Web Server, the user will be prompted with a dialogue box asking for credentials:


Once the user authenticates, the ACS (RADIUS or TACACS+ server) is queried. If authentication is successful, the User is said to "cut-through" the ASA to the Web Server. The credentials is automatically passed to the web server for authentication. There are four types of cut-through authentication:
-HTTP (80)
-HTTPS (443)
-Telnet (23)
-FTP (21)

This operation is very similar to Single Sign-On. The authentication ports supported by the cut-through proxy is fixed to the defaults listed above.

The configuration of the cut-through proxy can be split into three steps:
1) Create the RADIUS or TACACS+ server group for authentication.
aaa-server CTPRADIUS protocol RADIUS
2) Designate an authentication server and the PSK.
aaa-server CTPRADIUS (DMZ) host 2.2.2.2
key cisco
3) Enable cut-through proxy authentication by configuring a rule (a rule is defined using an access-list specifying the interesting traffic).
access-list CTPINTERESTING extended permit tcp any 2.2.2.0 255.255.255.0
aaa authentication match CTPINTERESTING OUTSIDE CTPGROUP

Of course, do note that ASA does not only support RADIUS and TACACS+, but it also supports NT, Kerberos, LDAP and other authentication methods. Once you are authenticated, you can see the authenticated users by typing:
show aaa local user

You can display customized prompts when the user authenticates through the cut-through proxy. We can configure the text for both successful and failed authentication attempts. To do this, we'll need to type:
auth-prompt prompt Please authenticate with the cut-through proxy!
auth-prompt accept Authentication accepted!
auth-prompt reject Authentication rejected!

The time the user is allowed to stay authenticated can either be absolute (e.g. 10 minutes) or based on inactivity (e.g. inactive for 10 minutes). From the ASDM, we can go to Configuration - Firewall - Advanced - Global Timeouts. To change these timers from the CLI, type:
timeout uauth 0:5:0 inactivity

Now it comes to authorization. There are two type of authorization methods:
1) Classic User - The AAA user is authorized based on the AAA server. This is TACACS+ only.
2) Per-User ACL - Each user (or group) is assigned a dynamic ACL when they connect. This is only supported by RADIUS.

To configure the downloadable ACLs from the ACS interface, we'll need to go to Interface Configurations - Advanced Options - Downloadable IP ACL Content. In the Window, we'll type access-list commands similar to IP Access-lists like this:
permit tcp any host 2.2.2.3 eq 80
permit tcp any host 2.2.2.3 eq 443

To designate which user gets which ACL, we'll go to User Setup and check Assign IP ACL. We can also designate group ACLs by going to the Groups section.

We can also configure to override ACLs per-user from the ASDM by going to Configuration - Firewall - Access Rules - Per User Override Setting. If the Per User Override settings is enabled, the downloaded access-list REPLACES the configured inbound interface ACL. If it is disabled, the ACL is MERGED with the configured interface ACL.