Using TACACS for Group Configuration
Using TACACS+ for Group ConfigurationTACACS+ is the next generation of the TACACS protocol, which was a lightweight User Datagram Protocol (UDP) designed for access control by BBN, now a Verizon Company for the MILNET. The TACACS+ protocol enhances the functionality of the TACACS protocol by separating authentication, authorization, and accounting. TACACS+ also encrypts all traffic between the AAA client and the TACACS+ service daemon that runs on a server, such as ACS. TACACS+ uses TCP port 49 in communications. The CSTacacs service of ACS listens on port 49. To begin your configuration of ACS TACACS+ settings, you need to have a plan as to how you want to implement TACACS+. In this section, you can assign an inbound access control list, an outbound access control list, or a route, or enable routing. The ability to configure time-of-day restrictions can also be enabled in the interface configuration. Each dial-in network varies. NOTE You can find more information on PPP configurations on the Cisco website at Cisco.com. Note that you can configure shell (EXEC) TACACS+ settings to be applied to the group for all users here. You can enable some very basic configurations here, and, of course, you can configure many intermediate to advanced configurations here. The purpose of this section is not to give you the how-to for every configuration available, but rather to give you configuration examples to help you better understand how the ACS reacts with AAA clients using TACACS+ for additional configurations. NOTE I have always thought that seeing is believing. Along with believing comes the understanding of how the protocol works. The example that you see here is one of the configurations that actually made that light bulb go off for me. The true test is to just try your ideas. Basic TACACS+In this example, you use TACACS+ to perform some authorization and an autocommand. Follow these steps to complete this example:
Note that, once again, the local tag is present. With this present, you need to enable the local command authorization on the Cisco router. You also need to add some additional configuration to the router to authorize for the commands in the menu admin1. These commands are seen in Example 8-4. Example 8-4. Router Authorization Commandsprivilege exec level 5 show ip interface brief privilege exec level 5 show interface privilege exec level 5 show run interface privilege exec level 5 show ip route privilege exec level 5 show arp privilege exec level 5 clear arp Figure 8-16 shows a sample of the basic network topology. Figure 8-16. Basic Network Topology
At this point, you need to configure the ACS server to perform the necessary authentication and authorizations. Begin the configuration on the ACS device by defining the router as an AAA client. Figure 8-17 shows an example of this. Figure 8-17. Adding an AAA Client to ACS After you define the router rbb in the ACS device, you might want to verify that junior-admin has an account on the ACS device. If not, be sure to create the junior-admin account. Assume that in this network environment, we have also created a group called ROUTER_ADMINS on our ACS device. At this point, you want to add junior-admin to the ROUTER_ADMINS group in ACS. When a member of the ROUTER_ADMINS group, junior-admin inherits the group settings unless otherwise configured at the user level. With junior-admin added to the ROUTER_ADMINS group, you can configure the group to run the autocommand when a user establishes a Telnet connection into the router. To enable the autocommand, simply follow these steps:
junior-admin is now authenticated through ACS, and the autocommand has been issued to the router. Now each command that is executed from the menu system is authorized as well. For some commands, junior-admin does not require any special configuration on the ACS. For commands that require a level 15 or privileged level access to rbb, the command needs to be entered into ACS in a separate command authorization set. With this configuration in place, you can now see the entire process by turning on the debug commands on rbb, debug aaa authentication and debug aaa authorization. Example 8-5 displays the authentication occurring during the login of junior-admin. Here, you see the messages passed between ACS and rbb. Example 8-5. Authentication Debug Output[View full width] 3w6d: AAA: parse name=tty131 idb type=-1 tty=-1 3w6d: AAA: name=tty131 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=131 channel=0 3w6d: AAA/MEMORY: create_user (0x62098664) user='' ruser='' port='tty131' rem_addr='192 In the debug outputs, you can see the user is authenticated and you can also see the start/stop accounting taking place. In Example 8-6, you see the authorization taking place using the debug aaa authorization command. In these messages you can see the TACACS+ AV (Attribute-Value) pairs. An AV pair is an Attribute, such as autocmd=, and a Value, such as menu admin1. Example 8-6. Authorization Debug Output[View full width] rbb#debug aaa authorization AAA Authorization debugging is on rbb# 3w6d: AAA: parse name=tty131 idb type=-1 tty=-1 3w6d: AAA: name=tty131 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=131 channel=0 3w6d: AAA/MEMORY: create_user (0x62098664) user='' ruser='' port='tty131' rem_addr='192 For the most part, this configuration works well for those new administrators. The problem here is that junior-admin is a member of the same group as the other administrators, those of whom are allowed more extensive access to the routers on the network. When any member of the administrator group Telnets to rbb, they receive the autocommand back from ACS, and no way to break out of the menu exists after they are there. Some of the options you have here are to edit the menu to allow a break out of the menu to the command line or to move the autocommand from the group configuration to the user configuration. This configuration appears to be a better solution in that when a user graduates to a new level of access, you simply remove the autocommand in ACS. Figure 8-19 displays the same type of autocommand configuration that you performed in Group Setup, only this is being performed at the user level in ACS. Notice that the configuration area in User Setup does not require a restart to the ACS service. This might be another motivating factor in determining how to approach the placement of the autocommand. Figure 8-19. User Level Autocommand Although this example seems to be very basic, it demonstrates a number of different functions and aspects of ACS. In this example, you can not only see authentication via ACS take place, but also see the "autocmd" AV pair in detail and command authorization. Shell Command Authorization SetsAnother aspect of TACACS+ in ACS is the Shell Command Authorization Sets. Here you have the ability to utilize shell command authorizations. In this section, you create two configurations using the same configuration areas in ACS. You most likely want to utilize these functions in separate groups. In Figure 8-20, you see the Shell Command Authorization Sets configuration fields. Figure 8-20. Shell Command Authorization Sets In this example, you see that the ROUTER_ADMINS group uses shell command authorization, implemented with the Cisco PIX Firewalls running OS version 6.2(2) to authorize command-line entries for junior-admin. Example 8-7 demonstrates the authentication and authorization configuration on the PIX Firewall. Figure 8-21 is a sample of this network. Figure 8-21. Command Authorization with the PIX Firewall You can configure command-line authorizations with other Cisco devices; however, only examples with the PIX Firewalls are discussed. Example 8-7 is the configuration that is used on the PIX Firewall. Example 8-7. PIX Configurationsaaa-server MYACS protocol TACACS+ aaa-server MYACS (inside) host 10.0.1.11 acskey aaa authentication enable console MYACS aaa authentication serial console MYACSaaa authentication ssh console MYACS aaa authentication telnet console MYACS aaa authorization command MYACS After you have the PIX Firewall configured with this command set, you can then use the enable command to authenticate to ACS. At this point, the authentication for junior-admin should pass, but the authorization would fail. The steps in the following step sequence are the same for the PIX as they would be for the routers and switch shell. This is because the pixshell service is not enabled in the PIX OS. What is important to understand here is that when you enable command authorization for your users, you also need to enable command authorization for yourself. This prevents you from being locked out of the equipment. To create a basic command authorization set, follow these steps:
This creates a "superuser" set. You now need to apply it to the group that this user is a member of. Figure 8-22 shows a sample of this command set. Figure 8-22. Shell Command Authorization Set To enable this command authorization set for users of the ROUTER_ADMINS group, follow these steps:
You also need to ensure that advanced TACACS+ options are enabled in Interface Configuration. To enable this, perform the following task:
You can now configure the authorization set. To do so, follow these steps:
User-Level AuthorizationAlthough the group-level command authorization provides an amount of security, it is not every situation that everyone in the group is given the same level. For situations such as this, you are going to take your command authorization a step further by configuring user-level command authorization. Before you begin configuring user-level authorization, ensure that it is enabled in Interface Configuration. Follow these steps to enable the option:
From this point on, you can configure user-level command authorization just as you would configure group-level authorization. As a point of reference, you should keep in mind that user attributes override group attributes. Configure a group-level command authorization policy that is relevant to most of the group members and minimizes the amount of configuration you perform at the individual user level. As a side note, when testing your configuration, create two users and apply the test settings to one individual user so that if by chance you are locked out of the device, you can access it with the other user account. Don't be afraid to experiment with the individual users. By now, you should have a firm understanding on both the ability to configure group items, while integrating other configurations such as downloadable PIX ACLs and Network Access Restrictions, as well as your ability to configure these at a user level for more specific policy settings. |
.168.1.1' authen_type=ASCII service=LOGIN priv=1 3w6d: AAA/AUTHEN/START (2194878578): port='tty131' list='' action=LOGIN service=LOGIN 3w6d: AAA/AUTHEN/START (2194878578): using "default" list 3w6d: AAA/AUTHEN/START (2194878578): Method=tacacs+ (tacacs+) 3w6d: TAC+: send AUTHEN/START packet ver=192 id=2194878578 3w6d: TAC+: Opening TCP/IP to 192.168.1.254/49 timeout=5 3w6d: TAC+: Opened TCP/IP handle 0x623C7668 to 192.168.1.254/49 3w6d: TAC+: periodic timer started 3w6d: TAC+: 192.168.1.254 req=62098014 Qd id=2194878578 ver=192 handle=0x623C7668 (ESTAB) 
EAN: 2147483647
Pages: 173