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 10.10.10.5
key bauxite
2. Configure the Authentication access-list
access-list AUTH extended permit tcp any host 2.2.2.2 eq telnet
virtual telnet 2.2.2.2
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 2.2.2.2 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 2.2.2.2 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 10.10.10.3 3070
Trying 10.10.10.3, 3070 ...
% Connection timed out; remote host not responding
R2#telnet 2.2.2.2
Trying 2.2.2.2 ... Open
LOGIN Authentication
Username: Amplebrain
Password:
Authentication Successful
[Connection to 2.2.2.2 closed by foreign host]
R2#telnet 10.10.10.3 3070
Trying 10.10.10.3, 3070 ... Open
User Access Verification
Password:
R1>
Show User Authentication on the ASA
ASA#sh uauth
Current Most Seen
Authenticated Users 1 1
Authen In Progress 0 1
user 'Amplebrain' at 192.168.1.2, 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!
Amplebrain
Thursday, December 31, 2009
Subscribe to:
Post Comments (Atom)
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).
ReplyDelete