cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
342
Views
3
Helpful
4
Replies

AAA/TACACS configuration for remote sites

absuizo14
Level 1
Level 1

We are about to implement AAA/TACACS admin authentication for switches on our remote site and we need to make sure that once we paste the script that we do not loose access to the remote switch. is there any tips on doing this without loosing access to the switch and needing to go onsite just to access the console. the script is provided below for reference:

!
aaa new-model
!
!
aaa group server tacacs+ AAA01
server-private key
server
ip tacacs source-interface Vlan17
!
aaa authentication login NETLOGIN group AAA01 local
aaa authorization exec NETLOGIN group AAA01 local
aaa authorization commands 15 NETLOGIN group AAA01 local
aaa authorization configuration NETLOGIN group AAA01
aaa accounting exec NETLOGIN start-stop group AAA01
aaa accounting commands 15 NETLOGIN start-stop group AAA01
!
line vty 0 4
authorization commands 15 NETLOGIN
authorization exec NETLOGIN
accounting commands 15 NETLOGIN
accounting exec NETLOGIN
login authentication NETLOGIN
transport input ssh
transport output ssh
line vty 5 15
authorization commands 15 NETLOGIN
authorization exec NETLOGIN
accounting commands 15 NETLOGIN
accounting exec NETLOGIN
login authentication NETLOGIN
transport input ssh
transport output ssh
!

 

1 Accepted Solution

Accepted Solutions

Arne Bier
VIP
VIP

It's always handy to perform a sanity check before issuing the IOS commands

  • Ensure that the devices exist in the AAA server (ISE or whatever) and that the IP address in the AAA matches that which is in your IOS config source interface.
  • Ensure that the TACACS+ shared secret in the IOS is identical to the one in the AAA server
  • Check each IOS device's source interface - if you are 100% it's always the same VLAN or loopback then well done - but I never trust that assumption - I come across devices that have mysterious/ancient configs that never got standardised!
  • Check each IOS device's TACACS+ config in case there device uses a VRF - ensure that the VRF (if used) is mentioned in the TACACS+ config.

Once that is done and confirmed, then you can proceed to configure a device.  As @johnd2310 mentioned, you can issue a "reload in 10" for extra belts and braces. However, I never do that in practice (I used to).  What I do now is a little more sophisticated.

ssh to the device

enter the commands up to  (but not including) the aaa commands

aaa new-model
aaa group server tacacs+ AAA01
 server-private key
 server xxxxx
 ip tacacs source-interface Vlan17
end

and then test the comms to the AAA server

test aaa group AAA01 testusername testpassword new-code

You can replace the testusername and testpassword with real credentials. if you use dummy credentials then the expected response on the CLI should be

Sending password
User rejected

else you'll see something like this

Sending password
User successfully authenticated

USER ATTRIBUTES

username "johnf"
reply-message "Enter password:"

At this point you're 100% sure you're talking to the AAA server.

What happens next is crucial. 

When you enter the aaa commands, you'll hit a roadblock when you enter the aaa authorization. Because, how the IOS is talking to the AAA server and will request authorization. At this point, simply log into the same device again, and then paste all the aaa commands again, starting from the aaa accounting .... statements

If you get locked out for whatever reason, don't panic. Go into the AAA server (e.g. ISE) and untick the TACACS+ box for that device. That will cause the IOS to get no response from AAA, and hence, fallback to local auth (as the case in your statement  aaa authentication login NETLOGIN group AAA01 local )

 

 

View solution in original post

4 Replies 4

johnd2310
Level 8
Level 8

Hi,

  • Schedule an outage for the switch
  • ssh to switch
  • Before pasting the config, issue the command "reload in 10"
  • paste config onto switch
  • if access to switch is lost, switch should reload after 10 minutes. After switch has rebooted, access what went wrong and try again
  • if access to switch is maintained  and AAA is working as desired, issue the command "reload cancel" to abort scheduled reboot.

Thanks

John

**Please rate posts you find helpful**

Wow this "reload in (minutes)" command is new to me. glad i asked this question here!

Arne Bier
VIP
VIP

It's always handy to perform a sanity check before issuing the IOS commands

  • Ensure that the devices exist in the AAA server (ISE or whatever) and that the IP address in the AAA matches that which is in your IOS config source interface.
  • Ensure that the TACACS+ shared secret in the IOS is identical to the one in the AAA server
  • Check each IOS device's source interface - if you are 100% it's always the same VLAN or loopback then well done - but I never trust that assumption - I come across devices that have mysterious/ancient configs that never got standardised!
  • Check each IOS device's TACACS+ config in case there device uses a VRF - ensure that the VRF (if used) is mentioned in the TACACS+ config.

Once that is done and confirmed, then you can proceed to configure a device.  As @johnd2310 mentioned, you can issue a "reload in 10" for extra belts and braces. However, I never do that in practice (I used to).  What I do now is a little more sophisticated.

ssh to the device

enter the commands up to  (but not including) the aaa commands

aaa new-model
aaa group server tacacs+ AAA01
 server-private key
 server xxxxx
 ip tacacs source-interface Vlan17
end

and then test the comms to the AAA server

test aaa group AAA01 testusername testpassword new-code

You can replace the testusername and testpassword with real credentials. if you use dummy credentials then the expected response on the CLI should be

Sending password
User rejected

else you'll see something like this

Sending password
User successfully authenticated

USER ATTRIBUTES

username "johnf"
reply-message "Enter password:"

At this point you're 100% sure you're talking to the AAA server.

What happens next is crucial. 

When you enter the aaa commands, you'll hit a roadblock when you enter the aaa authorization. Because, how the IOS is talking to the AAA server and will request authorization. At this point, simply log into the same device again, and then paste all the aaa commands again, starting from the aaa accounting .... statements

If you get locked out for whatever reason, don't panic. Go into the AAA server (e.g. ISE) and untick the TACACS+ box for that device. That will cause the IOS to get no response from AAA, and hence, fallback to local auth (as the case in your statement  aaa authentication login NETLOGIN group AAA01 local )

 

 

Thank you so much for this!