Thursday, December 31, 2009

ASA Cut-Through Proxy Part 2: Radius Authorization

AAA Authorization and Authentication are two separate processes. Authorization must be performed after Authentication has taken place. That makes sense because we have to know who the user is before we can know what he can do right?

While User Authentication and Authorization are separate processes, they are implemented together in the RADIUS server. The User is Authenticated and downloadable access-lists are used to perform Authorization for the user.
From a configuration perspective, no further authorization command is needed on the ASA as the authentication and authorization is performed at once on the RADIUS server.

From the radius server perspective, there are two ways to accomplish authoriztaion.

1. The radius server can reference an ACL configured on the ASA which is now 'activated' after the user has authenticated. In this case, the access-list name is specified under the radius attribute 11 (filter-id). The access-list can also be specified under the cisco AV pair (009,001) attribute.

2. The Access-list entries can be defined on the ACS server and downloaded unto the ASA after the user has authenticated.
Downloadable access-lists can be created on the server using the Advanced downloadable access-list features, (This must be activated from the Interface configuration tab). Check the box for "group-level downloadable access-lists"

The other option is to specify the access-list entries in the cisco-av-pair using the "inbound access-list" syntax.

ip:inacl#[acl-line-number]=[acl permit/deny statement] for example:

ip:inacll#1=permit ip any any

Note that there must be an authentication protocol for authorization to work, if none of the authentication protocols (telnet, http(s) or ftp) is configured, then the virtual telnet/http command should be used.

Consider the following same topology as the previous post;

R1 --- (inside)ASA(outside) -- R2 where the Radius server is on the inside interface.

The user would be authorized to telnet from the outsude interface to R1 on port 3070.

1. Configure the authentication AAA server on the ASA.

aaa-server ACS protocol radius

aaa-server ACS (inside) host

key bauxite

2. Configure the Authentication access-list

access-list AUTH extended permit tcp any host eq telnet

virtual telnet

3. Since it is on the outside the access-list must be configured to allow the authentication traffic:

access-list OUTSIDE_IN permit tcp any host eq telnet

access-group OUTSIDE_IN in interface outside

4. Configure AAA for authentication

aaa authentication match AUTH inside ACS

5. Configure the AAA server: To keep things simple, we would define the access-list test_auth on the ASA and then refer to it through the filter-id attribute of the RADIUS server:

access-list test_auth extended permit tcp any any eq 3070

access-list test_auth extended permit tcp any host eq telnet

The 2nd line of the acl is added so that the telnet session for authentication does not die after the authorization has taken place on the ASA. If the telnet session is not allowed by the authorization acl, though authorization would still take place, the telnet session would die immediately after the user is authorized and an error would be returned (though the process was successful), we would rather add the line for sanity sake. :-)

On the Radius server:

6. Enable Per-user override on the inbound access list on the outside interface;

This makes the downloaded access-list take precedence over the existing interface access-list

access-group OUTSIDE_IN in interface outside per-user-override

7. Verification

Enable telnet on port 3070 on R1

line con 0

rotary 70

password cisco

Before Authorization:

R2#telnet 3070

Trying, 3070 ...

% Connection timed out; remote host not responding


Trying ... Open

LOGIN Authentication

Username: Amplebrain


Authentication Successful

[Connection to closed by foreign host]

R2#telnet 3070

Trying, 3070 ... Open

User Access Verification



Show User Authentication on the ASA

ASA#sh uauth

Current Most Seen

Authenticated Users 1 1

Authen In Progress 0 1

user 'Amplebrain' at, authenticated

access-list test_auth (*)

absolute timeout: 0:05:00

inactivity timeout: 0:00:00

As I mentioned earlier, Authorization can also be accomplished using the tacacs+ protocol but this is implented entirely differently. I hope to put up a post on this sometime in the future.

Anyway, this is the last technical post for the year 2009!

Wishing everyone a prosperous 2010...Cheers!


1 comment:

  1. Thank you for the clear explanation. The 'per-user-override' solved the one big hurdle I had in implementing authorization (I didn't want users already in the system, with no ACLs bound to them, to have full access).