Cisco Routers And AAA (Part 1 – Authentication)
CCNA Security Tutorial:
An Introduction To AAA
(And Why Do We Need Three As, Anyway?)
Chris Bryant, CCIE #12933
When you think of "AAA", different things may come to mind...
... the always-helpful American Automobile Association...... the letters that certain types of businesses put in front of their name so they appear first in the phone book (or so I hear)...... or up to 86 other things!
In CiscoLand, "AAA" stands for Authentication, Authorization, and Accounting. In this CCNA Security & CCNP ISCW tutorial series, we'll take a look at each of those "As" and exactly what each does to help keep our networks secure.
We'll start with a network security fundamental - Authentication.
(Hang in there, there are illustrations in the second half of this tutorial!)
The First "A" - Authentication
Authentication is simply the process of deciding if a given user should be allowed to access the network or a network service.
As
a CCNA and future CCNP, you've already configured authentication in
the form of creating a local database of usernames and passwords for
both Telnet access and PPP authentication.
This is sometimes called a self-contained AAA deployment, since no external server is involved.
It's more than likely that you'll be using a server configured for one of the following security protocols:
TACACS+, a Cisco-proprietary, TCP-based protocolRADIUS, an open-standard, UDP-based protocol originally developed by the IETF
An
obvious question is "If there's a TACACS+, what about TACACS?" TACACS
was the original version of this protocol and is rarely used today.
Before we head into AAA Authentication configuration, there are some other TACACS+ / RADIUS differences you should be aware of:
While TACACS+ encrypts the entire packet, RADIUS encrypts only the password in the initial client-server packet.RADIUS actually combines the authentication and authorization processes, making it very difficult to run one but not the other.TACACS+ considers Authentication, Authorization, and Accounting to be separate processes. This allows another method of authentication to be used (Kerberos, for example), while still using TACACS+ for authorization and accounting.RADIUS does not support the Novell Async Services Interface (NASI) protocol, the NetBIOS Frame Protocol Control protocol, X.25 Packet Assembler / Disassembler (PAD), or the AppleTalk Remote Access Protocol (ARA or ARAP). TACACS+ supports all of these.RADIUS implementations from different vendors may not work well together, or at all.RADIUS can't control the authorization level of users, but TACACS+ can.
Any
time you see differences between two network services that do
basically the same thing, that's highly fertile ground for exam
questions. :)
Regardless of which "A" you're configuring, AAA must be enabled with the global command aaa new-model.
The location of the TACACS+ and / or RADIUS server must then be
configured, along with a shared encryption key that must be agreed upon
by the client and server.
Since you're on the way to the CCNP, that's what we'll use here for the key.
R1(config)#aaa new-model
R1(config)#tacacs-server host 172.1.1.1 key CCNP
R1(config)#radius-server host 172.1.1.2 key CCNP
The aaa new-model command carries out two tasks:
enables AAAoverrides every previously configured authentication methods for the router lines - especially the VTY lines!
More on that "especially the vty lines" a little later in this tutorial.
Multiple
TACACS+ and RADIUS servers can be configured, and the key can either
be included at the end of the above commands or separate from that, as
shown below.
R1(config)#tacacs-server key CCNP
R1(config)#radius-server key CCNP
R1(config)#radius-server key CCNP
Now
comes the interesting part! We've got a TACACS+ server at 172.1.1.1,
a RADIUS server at 172.1.1.2, and the router is configured as a
client of both with a shared key of CCNP for both.
So if we have multiple Authentication servers, who decides which to use first or at all?
The network admin does - and that's us!
The network admin does - and that's us!
More of this CCNA Security tutorial right after this brief and important message.
Now let's get back to AAA...
We've
got a TACACS+ server at 172.1.1.1, a RADIUS server at 172.1.1.2, and
the router is configured as a client of both with a shared key of CCNP
for both.
We need to determine which servers will be used for Authentication, and in what order, with the aaa authentication command. Let's take a look at the options:
R1(config)#aaa authentication login ?
WORD Named authentication list.
default The default authentication list.
WORD Named authentication list.
default The default authentication list.
We have two choices:
A named authentication list. Much like a named ACL, this type of list is used for authentication when specifically mentioned by its name.A default authentication list, used when a named authentication list is not mentioned in the authentication configuration.
In this example, we'll create a default list.
R1(config)#aaa authentication login default ?
enable Use enable password for authentication.
group Use Server-group
line Use line password for authentication.
local Use local username authentication.
local-case Use case-sensitive local username authentication.
none NO authentication.
enable Use enable password for authentication.
group Use Server-group
line Use line password for authentication.
local Use local username authentication.
local-case Use case-sensitive local username authentication.
none NO authentication.
Remember
our old friend the enable password ? We can configure Authentication
to use the enable password, and we could also use a line password.
More common is local username authentication,
which will use a database local to the router. That sounds
complicated, but to build a username/password database, just use the username/password command!
R1(config)#username gagne password awa
R1(config)#username afflis password wwa
R1(config)#username thesz password nwa
R1(config)#username afflis password wwa
R1(config)#username thesz password nwa
The
username / password command creates a local database that can be used
for multiple purposes, including authenticating Telnet users.
We
could create a local database and use it for AAA Authentication,
but in this example we'll use the TACACS+ and RADIUS servers. To do
so, we need to drill a little deeper with the aaa authentication command.
R1(config)#aaa authentication login default group ?
WORD Server-group name
radius Use list of all Radius hosts.
tacacs+ Use list of all Tacacs+ hosts.
WORD Server-group name
radius Use list of all Radius hosts.
tacacs+ Use list of all Tacacs+ hosts.
R1(config)#aaa authentication login default group radius ?
enable Use enable password for authentication.
group Use Server-group
line Use line password for authentication.
local Use local username authentication.
local-case Use case-sensitive local username authentication.
none NO authentication.
<cr>
enable Use enable password for authentication.
group Use Server-group
line Use line password for authentication.
local Use local username authentication.
local-case Use case-sensitive local username authentication.
none NO authentication.
<cr>
R1(config)#aaa authentication login default group radius group tacacs
The group radius and group tacacs
commands configure the router to use those devices for Authentication -
but it's interesting that we were able to configure more than one
Authentication source.
Actually,
we can name a maximum of four methods, and they'll be used in the
order listed. In the above command, the default list will check the
RADIUS server first. If there's an error or a timeout , the second
method listed will be checked.
It's very important to note that if a user's authentication attempt is refused by the first method, the second method is not used, and the user's authentication attempt will fail.
Did you notice that "none" was an authentication option?
R1(config)#aaa authentication login default group radius ?
enable Use enable password for authentication.
group Use Server-group
line Use line password for authentication.
local Use local username authentication.
local-case Use case-sensitive local username authentication.
none NO authentication.
<cr>
enable Use enable password for authentication.
group Use Server-group
line Use line password for authentication.
local Use local username authentication.
local-case Use case-sensitive local username authentication.
none NO authentication.
<cr>
If you're concerned that all prior listed methods of authentication may result in an error or timeout, you can configure none at the end of the aaa authentication command.
Of course, if none
is the only option you select, you've effectively disabled
authentication. Here, I've configured a default list on R3 that is
using only one authentication option - none! I then apply that list to the vty lines and attempt to telnet to R3 from R1.
R3(config)#aaa new-model
R3(config)#aaa authentication login default none
R3(config)#line vty 0 4
R3(config-line)#login authentication default
R3(config)#aaa authentication login default none
R3(config)#line vty 0 4
R3(config-line)#login authentication default
R1#telnet 172.12.13.3
Trying 172.12.13.3 ... Open
Trying 172.12.13.3 ... Open
R3>
Note that I was not prompted for a vty password. We probably don't want that. :)
That takes care of the first "A" - and in the next part of our CCNA Security / CCNP ISCW tutorial, we'll tackle the other two!
Be sure to take advantage of my $20 CCNA Security certification offer, and thanks for making The Bryant Advantage part of your CCNA and CCNP studies!
Chris Bryant
CCIE #12933
"The Computer Certification Bulldog"
Nguồn: cisco.tutbook.net
Không có nhận xét nào:
Đăng nhận xét