Skip to main content

ACS, tacacs+ and management access to router

I would like to test tacacs+ authentication on routers. 
 
R1#sh run aaa
!
aaa authentication login ACS group tacacs+
aaa authentication enable default group tacacs+
!
!
!
!
!
!
tacacs-server host 192.168.157.100 key cisco
aaa new-model
aaa session-id common
!
!

R1#
R1#sh run | b line vty 0 4
line vty 0 4
 login authentication ACS
!

On ACS I added R1 as ND and ‘user1’ to the local database.
 
telnet 192.168.157.100

R1#
*Aug 27 15:37:05.071: TPLUS: Queuing AAA Authentication request 49 for processing
*Aug 27 15:37:05.075: TPLUS: processing authentication start request id 49
*Aug 27 15:37:05.079: TPLUS: Authentication start packet created for 49()
*Aug 27 15:37:05.079: TPLUS: Using server 192.168.157.100
*Aug 27 15:37:05.087: TPLUS(00000031)/0/NB_WAIT/685E7C1C: Started 5 sec timeout
*Aug 27 15:37:05.099: TPLUS(00000031)/0/NB_WAIT: socket event 2
*Aug 27 15:37:05.103: TPLUS(00000031)/0/NB_WAIT: wrote entire 37 bytes request
*Aug 27 15:37:05.107: TPLUS(00000031)/0/READ: socket event 1
*Aug 27 15:37:05.111: TPLUS(00000031)/0/READ: Would block while reading
R1#
*Aug 27 15:37:05.119: TPLUS(00000031)/0/READ: socket event 1
*Aug 27 15:37:05.123: TPLUS(00000031)/0/READ: read entire 12 header bytes (expect 16 bytes data)
*Aug 27 15:37:05.123: TPLUS(00000031)/0/READ: socket event 1
*Aug 27 15:37:05.127: TPLUS(00000031)/0/READ: read entire 28 bytes response
*Aug 27 15:37:05.127: TPLUS(00000031)/0/685E7C1C: Processing the reply packet
*Aug 27 15:37:05.127: TPLUS: Received authen response status GET_USER (7)
R1#
*Aug 27 15:37:10.667: TPLUS: Queuing AAA Authentication request 49 for processing
*Aug 27 15:37:10.671: TPLUS: processing authentication continue request id 49
*Aug 27 15:37:10.675: TPLUS: Authentication continue packet generated for 49
*Aug 27 15:37:10.675: TPLUS(00000031)/0/WRITE/685E7C1C: Started 5 sec timeout
*Aug 27 15:37:10.679: TPLUS(00000031)/0/WRITE: wrote entire 22 bytes request
*Aug 27 15:37:10.691: TPLUS(00000031)/0/READ: socket event 1
*Aug 27 15:37:10.695: TPLUS(00000031)/0/READ: read entire 12 header bytes (expect 16 bytes data)
*Aug 27 15:37:10.695: TPLUS(00000031)/0/READ: socket event 1
R1#
*Aug 27 15:37:10.699: TPLUS(00000031)/0/READ: read entire 28 bytes response
*Aug 27 15:37:10.699: TPLUS(00000031)/0/685E7C1C: Processing the reply packet
*Aug 27 15:37:10.699: TPLUS: Received authen response status GET_PASSWORD (8)
R1#
*Aug 27 15:37:13.499: TPLUS: Queuing AAA Authentication request 49 for processing
*Aug 27 15:37:13.503: TPLUS: processing authentication continue request id 49
*Aug 27 15:37:13.507: TPLUS: Authentication continue packet generated for 49
*Aug 27 15:37:13.511: TPLUS(00000031)/0/WRITE/685E7C1C: Started 5 sec timeout
*Aug 27 15:37:13.515: TPLUS(00000031)/0/WRITE: wrote entire 22 bytes request
*Aug 27 15:37:13.551: TPLUS(00000031)/0/READ: socket event 1
*Aug 27 15:37:13.551: TPLUS(00000031)/0/READ: read entire 12 header bytes (expect 6 bytes data)
*Aug 27 15:37:13.555: TPLUS(00000031)/0/READ: socket event 1
R1#
*Aug 27 15:37:13.555: TPLUS(00000031)/0/READ: read entire 18 bytes response
*Aug 27 15:37:13.555: TPLUS(00000031)/0/685E7C1C: Processing the reply packet
*Aug 27 15:37:13.559: TPLUS: Received authen response status PASS (2)
R1#

As we see I received positive response. Now I try to enter to exec mode:
 
R1>en
password:
% Error in authentication.

R1>


R1#
*Aug 27 15:39:25.795: TAC+: send AUTHEN/START packet ver=192 id=731471408
*Aug 27 15:39:25.799: TAC+: Using default tacacs server-group "tacacs+" list.
*Aug 27 15:39:25.799: TAC+: Opening TCP/IP to 192.168.157.100/49 timeout=5
*Aug 27 15:39:25.867: TAC+: Opened TCP/IP handle 0x6949CD48 to 192.168.157.100/49
*Aug 27 15:39:25.871: TAC+: 192.168.157.100 (731471408) AUTHEN/START/LOGIN/ASCII queued
*Aug 27 15:39:26.071: TAC+: (731471408) AUTHEN/START/LOGIN/ASCII processed
*Aug 27 15:39:26.079: TAC+: ver=192 id=731471408 received AUTHEN status = GETPASS
R1#
*Aug 27 15:39:30.543: TAC+: send AUTHEN/CONT packet id=731471408
*Aug 27 15:39:30.543: TAC+: 192.168.157.100 (731471408) AUTHEN/CONT queued
*Aug 27 15:39:30.743: TAC+: (731471408) AUTHEN/CONT processed
*Aug 27 15:39:30.747: TAC+: ver=192 id=731471408 received AUTHEN status = FAIL
*Aug 27 15:39:30.751: TAC+: Closing TCP/IP 0x6949CD48 connection to 192.168.157.100/49
R1#

There is something wrong with authentication. Let’s check logs on ACS.
I found one entry related to my problem:
 
Authentication Details 
Status: Failed 
Failure Reason: 13029 Requested privilege level too high

Logged At: Jan 1, 2014 3:05 AM 
ACS Time: Jan 1, 2014 3:05 AM 
ACS Instance: acs

Authentication Method: PAP_ASCII 
Authentication Type: ASCII 
Privilege Level: 15 
User 
Username: user1

Remote Address: 192.168.157.1 
Network Device 
Network Device: r1

Network Device IP Address: 192.168.157.11 
Network Device Groups: Device Type:All Device Types, Location:All Locations

I have to change ‘assigned’ and ‘max’ privilege level:

Policy Elements->Authorization and Permissions->Device Administration->Shell Profiles:
in my case I set 8 and 15.

Next I have to add this profile to ‘Device Administration Authorization Policy’:

Access Policies->Access Services->Default Device Admin->Authorization.

Then I test ‘enable’ once again:
 
R1>en
password:


R1#
*Aug 27 20:10:14.282: TAC+: send AUTHEN/START packet ver=192 id=-2094635717
*Aug 27 20:10:14.282: TAC+: Using default tacacs server-group "tacacs+" list.
*Aug 27 20:10:14.286: TAC+: Opening TCP/IP to 192.168.157.100/49 timeout=5
*Aug 27 20:10:14.302: TAC+: Opened TCP/IP handle 0x675570A0 to 192.168.157.100/49
*Aug 27 20:10:14.306: TAC+: 192.168.157.100 (2200331579) AUTHEN/START/LOGIN/ASCII queued
*Aug 27 20:10:14.506: TAC+: (2200331579) AUTHEN/START/LOGIN/ASCII processed
*Aug 27 20:10:14.510: TAC+: ver=192 id=-2094635717 received AUTHEN status = GETPASS


R1#
*Aug 27 20:10:17.154: TAC+: send AUTHEN/CONT packet id=-2094635717
*Aug 27 20:10:17.158: TAC+: 192.168.157.100 (2200331579) AUTHEN/CONT queued
*Aug 27 20:10:17.358: TAC+: (2200331579) AUTHEN/CONT processed
*Aug 27 20:10:17.362: TAC+: ver=192 id=-2094635717 received AUTHEN status = PASS
*Aug 27 20:10:17.362: TAC+: Closing TCP/IP 0x675570A0 connection to 192.168.157.100/49
R1#

But I see I’m placed in privilege level 15, not 8, as I configured.
 
R1#sh priv
Current privilege level is 15
R1#

To be placed in correct privilege level I have to add following authorization command:
 
aaa authorization exec default group tacacs+

Let’s try once again:
 
telnet 192.168.157.11
Trying 192.168.157.11 ... Open

username: user1
password:

R1#sh priv
Current privilege level is 8
R1#

Now I would like to add some limits for available commands for user1. Assume the user should be able to enter into config mode and be able to shutdown all FastEthernet interfaces.

First I have to add authorization command: 
 
R1(config)#aaa authorization commands 15 default group tacacs+
R1(config)#aaa authorization config-commands

On ACS I have to add one ‘Command Sets’:
 
permit configuration terminal
permit interface FastEthernet
permit shutdown

Don’t forget to add ‘Command Sets’ to Authorization Policy results. Last step is to update Authorization Policy.
 
username: user1
password:

R1#sh priv
Current privilege level is 8
R1#configure terminal
      ^
% Invalid input detected at '^' marker.

R1#en
password:
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.

R1(config)#interface Loo0
Command authorization failed.

R1(config)#interface Fas
R1(config)#interface FastEthernet ?
  <0-7>  FastEthernet interface number

R1(config)#interface FastEthernet1/0
R1(config-if)#ip add
R1(config-if)#ip address 1.1.1.1 255.255.255.0
Command authorization failed.

R1(config-if)#shu
R1(config-if)#shutdown
R1(config-if)#no shu
R1(config-if)#no shutdown
Command authorization failed.

R1(config-if)#
 
As you see we accomplished all requirements, user1 is able to issue only selected commands.
Labels:

Comments

Post a Comment

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an ...
8 comments
Read more

FortiGate and GRE tunnel

Recently I worked on one project where a client requested to re-route web traffic to the GRE tunnel to perform traffic inspection. I would like to share with you what is required if you configure it on FortiGate. We need a new GRE interface and policy base routing (PBR) to change the route for specific source IPs. Of course you need firewall policies to permit the traffic. Let's start with GRE interface. Unfortunately you can't configure it using the GUI, only CLI is the option: config system gre-tunnel edit "gre1" set interface "port1" set local-gw 55.55.55.55 set remote-gw 44.44.44.44 next end When the end peer is Cisco router, you need to set the IP for the GRE interface: config system interface edit gre1 set ip 192.168.10.10 255.255.255.255 set remote-ip192.168.10.20 end In next step we need to fix routing. We need the alternate path via GRE but to keep the route in the active routing table you need to set the same AD (adminis...
Post a Comment
Read more

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze ...
1 comment
Read more