AAA server (part 3)

Cisco Routers And AAA( part 2-Authorization)

CCNA Security Certification And CCNP SWITCH Tutorial:

The "Authorization" In AAA

Chris Bryant, CCIE #12933 

In the first installment of this CCNA Security AAA tutorial, we took a look at the first "A" - Authentication - and defined exactly what role that "A" plays in network security.

Today's "A" is for Authorization - - and the natural question is "Aren't Authentication and Authorization the same thing?"

Not quite! Authentication decides whether a given user should be allowed into the network; Authorization dictates what users can do once they are in.

The aaa authorization command creates a user profile that is checked when a user attempts to use a particular command or service. 

As with Authentication, we'll have the option of creating a default list or a named list, and naturally AAA must be globally enabled with the aaa new-model command before you begin your Authorization configuration.

R1(config)#aaa new-model

R1(config)#aaa authorization ?
  auth-proxy       For Authentication Proxy Services
  commands         For exec (shell) commands.
  config-commands  For configuration mode commands.
  configuration    For downloading configurations from AAA server
  exec             For starting an exec (shell).
  network          For network services. (PPP, SLIP, ARAP)
  reverse-access   For reverse access connections

R1(config)#aaa authorization exec ?
  WORD     Named authorization list.
  default  The default authorization list.

R1(config)#aaa authorization exec default ?
  group             Use Server-group
  if-authenticated  Succeed if user has authenticated.
  local             Use local database.
  none              No authorization (always succeeds).

Now we're going to revisit an old CCNA friend... privilege levels.

Privilege Levels And AAA Authorization

Privilege levels define what commands a user can actually run on a router.   There are three predefined privilege levels on Cisco routers, two of which you've been using since you started your Cisco studies - even if you didn't know it! 

When you're in user exec mode, you're actually in privilege level 1, as verified with show privilege :

R2>show privilege
Current privilege level is 1

By moving to privileged exec mode with the enable command, you move from level 1 to level 15, the highest level:

R2>show privilege
Current privilege level is 1
R2>enable
R2#show privilege
Current privilege level is 15

There's actually a third predefined privilege level, Level Zero, which allows the user to run the commands exit, logout, disable, enable , and logout.  Obviously, a user at Level Zero can't do much.

There's a huge gap in network access between levels 1 and 15, and the remaining levels 2-14 can be configured to fill that gap. 

Levels 2 - 14 can be configured to allow a user assigned a particular privilege level to run some commands, but not all of them. 

Assume you have a user who should not be allowed to use the ping command, which by default can be run from privilege level 1:

R2>ping 172.1.1.1      (Success of the ping has been edited)

By moving the ping command to privilege level 5, a user must have at least that level of privilege in order to use ping.  To change the privilege level of a command, use the privilege command.  (IOS Help shows approximately 30 options following privilege, so I won't put all of those here.)

R2(config)#privilege ?
  address-family     Address Family configuration mode
  configure          Global configuration mode
  congestion         Frame Relay congestion configuration mode
  dhcp               DHCP pool configuration mode
  exec               Exec mode  

R2(config)#privilege exec ?
  level  Set privilege level of command
  reset  Reset privilege level of command

R2(config)#privilege exec level ?
  <0-15>  Privilege level

R2(config)#privilege exec level 5 ?
  LINE  Initial keywords of the command to modify

R2(config)#privilege exec level 5 ping

A user must now have at least a privilege level of 5 to send a ping.  Let's test that from both level 1 and 15.

First, from level 1:

R2>ping 172.1.1.1
        ^
% Invalid input detected at '^' marker.

And now from level 15:

R2#ping 172.1.1.1    (Success of ping edited)

Note the user at Level 1 is not told they're being denied access to this command because of privilege level.  The ping works successfully from Level 15.

There are two options for assigning privilege levels to users, one involving AAA and one not.  To enable AAA Authorization to use privilege levels, use the aaa authorization command followed by the appropriate option:

R2(config)#aaa authorization ?
  auth-proxy         For Authentication Proxy Services
  commands           For exec (shell) commands.
  config-commands    For configuration mode commands.
  configuration      For downloading configurations from AAA server
  exec               For starting an exec (shell).
  network            For network services. (PPP, SLIP, ARAP)
  reverse-access     For reverse access connections

The full command to use the TACACS+ server to assign privilege levels, followed by the local database, is as follows:

R2(config)#aaa authorization commands 5 default group tacacs+ local

Getting authorization to work exactly the way you want it to does take quite a bit of planning and testing due to the many options. Don't become (too) frustrated if you don't get the desired results the first time around - this usually takes a bit of fine-tuning.

Privilege levels can also be assigned via the router's local database.  To do so, use the privilege option in the middle of the username/password command.

R2(config)#username chris privilege 5 password bryant

That would assign a privilege level of 5 to that particular user,and they could use all commands that have a privilege level of 5 or lower...not just the commands with a privilege level of exactly 5.

The Authorization feature of AAA can also assign IP addresses and other network parameters to Mobile IP users.   How this occurs is beyond the scope of the CCNA Security or ISCW exam, but you can refer to RFC 2905 for more details.  Perhaps more details than you'd like to know!

Two "A"s down, one to go! We'll take on the third "A" in the next CCNA Security / CCNP ISCW tutorial.

Thanks for making The Bryant Advantage part of your CCNA Security and CCNP studies!

Chris Bryant

CCIE #12933

"The Computer Certification Bulldog"

AAA server (part 2)

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 protocol

RADIUS, 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 AAA

overrides 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

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!

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.

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.

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

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.

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>

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>

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

R1#telnet 172.12.13.3
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