Using TACACS for AAA
Using TACACS+ for AAAMost Cisco devices, including IOS routers and switches, CatOS-based switches, PIX Firewalls, and VPN concentrators, have a built-in TACACS+ Client. To implement TACACS+-based AAA functionality, Netadmins must do the following:
The sections that follow provide details about the following items:
Deploying a Linux-Based TACACS+ ServerTo deploy a Linux-based TACACS+ Server, you must first have a Linux machine preconfigured with basic network settings. The examples depicted in this discussion were created in Debian Linux, which was installed on an Intel Pentium III-based workstation with 256 MB RAM and an Ethernet network interface card (NIC). Following is the partial list of UNIX/Linux-based TACACS+ Servers:
Of these three servers, this discussion covers TACACS+ freeware from Cisco for the following reasons:
Downloading the Installation FilesThe TACACS+ freeware for UNIX/Linux was developed by Cisco and is available under the open source license. Download and save the TACACS+ freeware installable files through FTP at ftp://anonymous@ftp-eng.cisco.com/pub/tacacs/. If you are prompted by the Cisco ftp site for a password, you can enter your e-mail address as the password. The name of the file is tac_plus.F4.0.4.alpha.tar.z. The tar.z extension indicates that the file is a compressed archive file in tar format. The tar file contains the TACACS+ Daemon. In this example, the TACACS+ Daemon is assumed to be saved in the /home directory. Note Throughout this chapter, the TACACS+ Daemon is referred to as the TACACS+ Server or simply as TACACS+. Likewise, the RADIUS Server and RADIUS Daemon are one and same. Professionals from the UNIX world use the term daemon, whereas those from Windows use server. Installing the TACACS+ DaemonAfter downloading the tar files, follow these steps to install the TACACS+ Daemon:
The TACACS+ Server is now ready for configuration. Tip Timesaver: For Debian Linux, avoid the four-step installation routine by using the single command apt-get install tac-plus. Configuring the Text FileThe TACACS+ Daemon is configured through a single configuration file in text format. Users can create a configuration file from scratch or customize the sample file created by the install script in the /usr/local/bin directory. Information regarding the configuration file is explained in the users_guide file. This file, included with the source tar file, can be found in the directory from which all the other install files were extracted. If you used the apt-get install tac-plus command to install the TACACS+ Daemon on a Debian system, the users_guide file is located in the /usr/share/doc/tac-plus/ directory. The configuration file controls the generic properties of the TACACS+ Daemon, including the TACACS+ encryption key, the default authentication mechanism, and the location of the accounting log file. The username, passwords, account expiry, exec shell authorization, and command authorization are also controlled through the configuration file. This file allows you to group multiple users under common groups for efficient management. Line entries beginning with # (the pound sign) are treated as comments. Example 3-1 shows the content of the sample file /etc/tac-plus/tacacs.conf after suitable edits. This file illustrates a typical configuration needed to run the TACACS+ Daemon. Example 3-1. /etc/tac-plus/tacacs.conf File ####################### # CONFIGURE ENCYPTION KEY key = VerYs3cr3taqskey ####################### # CONFIGURE DEFAULT AUTHENTICATION # Query the /etc/passwd file for default authentication default authentication = file /etc/passwd # Location of text file to log Accounting records ####################### # CONFIGURE ACCOUNTING LOG FILE accounting file = /var/log/tac.log ###################### # CONFIGURE GROUP ###################### # Network administrator group group = netadmin { # netadmin group for supervisor access default service = permit service = exec { priv-lvl = 15 } } # Regular user group group = regularusers { # regular users will be added to this group default service = deny service = exec { priv-lvl = 1 } } ###################### # CONFIGURE USERS ###################### # Netadmin users # note that there is no password entry # tacacs+ daemon will query the /etc/passwd file for this user user = spope { member = netadmin } # Users with limited privileges user = jkeith { member = regularusers login = cleartext "securepassword123" cmd = show { permit .* } cmd = exit { permit .* } cmd = telnet { permit 192\.168\.1\.[0-9]+ deny .* } } # Temp user account for consultant user = consultant1 { expires = "Dec 15 2005" login = des egCv7fX.G5FgQ service = exec { # When an exec is started, autocmd starts autocmd = "show ip interface brief" } } # End file The general format for specifying the parameters in the configuration file is attribute = value. The value might have additional subparameters. In such cases, the subparameters are enclosed in braces ({}). Caution You can use the chmod command to limit access to the configuration file because it contains sensitive information. The following example code shows that the file permissions are changed to allow read and write access for the root user only: linuxbox:~# chmod 600 /etc/tac-plus/tacacs.conf linuxbox:~# ls -l /etc/tac-plus/tacacs.conf -rw------- 1 root root 1855 Mar 20 22:27 tacacs.conf The following sections describe the significance of each component of the configuration file. The discussion also covers the syntax and sample code for each component. Configuring the Encryption KeyTACACS+ uses an encryption key to encrypt the packets. The same key is specified on both the client and the server. The syntax is key = tacacs-encryption-key. Configuring Default AuthenticationFor every user listed in the TACACS+ Daemon file, you must specify a password (discussed in the section "Configuring the Password (User Authentication)," later in this chapter. Manually maintaining the passwords for a large number of users can be cumbersome and inefficient. To circumvent this limitation, the TACACS+ Daemon can use the passwords listed in the /etc/passwd file on the local Linux servers to authenticate users. Before using the /etc/passwd file for authentication, you must define the users on the local Linux machine. For example, before adding user spope in the configuration file, you must create the user spope using the adduser command on the local Linux machine. Using the /etc/passwd file eliminates the need to specify a password for every user within the configuration file. The command syntax is default authentication = file location-of-password-file. Configuring the TACACS+ Daemon to use the /etc/passwd file enables users to change their passwords without accessing the configuration file. This feature frees the Netadmin from having to maintain individual passwords. Note The authentication mechanism of using the local passwords listed in the /etc/passwd file fails for secure Linux versions that use shadow passwords. In such cases, Debian Linux users can turn off the shadow password feature by using the shadowconfig off command. However, you should not turn off this feature for security reasons. For more information on shadow passwords, visit the following URL:
Configuring GroupsGroups provide an easy way to group similar users. Instead of modifying the properties of each user, you can simply modify the properties of the group to which the users belong. Apart from saving time, groups also provide ease and efficiency in managing a large number of users. The syntax for configuring groups is as follows: group = group-name { # comments for describing the group attribute-1 = value { attribute-2 = value } . . . attribute-n = value } The attribute and value are used to specify authentication and authorization information (discussed in the following sections) for the group. Example 3-1 shows two groups netadmin and regularusers. The following excerpt shows just the group and description from the configuration file: group = netadmin { # netadmin group for supervisor access } group = regularusers { # regular users will be added to this group } Configuring UsersThe most important element of the configuration file, and, in turn, the TACACS+ Daemon, is the username. Without a username, authentication cannot occur. Moreover, without authentication, neither authorization nor accounting can occur. Although, there is no documented limit to the number of users you can create, the TACACS+ Daemon has been tested successfully with 75,000 usernames. You can optionally assign each user to any group; however, the TACACS+ user can only belong to a single TACACS+ group. You can define parameters such as the group membership and authentication and authorization properties for each user under the user's profile. The syntax is as follows: user = username { # comment for describing the user member = groupname attribute-1 = value { attribute-2 = value } . . . attribute-n = value } If the user also belongs to a group, the properties defined for the user take precedence over those defined for his group. Consider a case of user joe being defined as a member of the sysadmin group. If the expiration date (discussed in the section "Configuring Expiration Dates," later in this chapter) for user joe is defined as January 2, 2006, but that for the sysadmin group is March 3, 2006, Joe's account will expire after January. The following is an excerpt from Example 3-1, showing just three users and their group membership: user = spope { # user spope is a member of netadmin group member = netadmin } user = jkeith { # jkeith is a member of regularusers group member = regularusers } user = consultant1 { # consultant1 is a not member of any group } While spope and jkeith are defined as members of the netadmin and regularusers groups, respectively, consultant1 is not a member of any group. The netadmin group has administrative privileges that allow unrestricted access, while regularusers has limited privileges. A typical case of limited privilege is help-desk or remote-admin staff, who can only view device status but cannot change any configuration. In other cases, such as a temporary consultant, you should provide that person with extremely limited access. Configuring the Password (User Authentication)Despite defining the default authentication at the top level, per-user authentication can be defined under each user profile. The user authentication password can be specified as clear text or DES encrypted, or from the /etc/passwd file. The syntax for the three possible values is as follows: user = username1 { login = cleartext password-in-clear-text } user = username2 { login = des DES-encryptedin-password } user = username3 { login = file path-to-local-file } Note that the clear-text password is accessible to anyone who can access the configuration file. To overcome this security limitation, you can use encrypted passwords. The TACACS+ Daemon includes a utility, called generate_passwd, that allows you to create DES-encrypted passwords from clear-text passwords. You can manually copy and paste the encrypted password into the configuration file, but manually copying each password can be cumbersome for a large number of users. In such cases, you can instruct the TACACS+ Daemon to use the local passwords that are contained in the /etc/passwd file for the user. Note that the username and password should be defined on the local Linux machine; passwords should be defined using the Linux command passwd username. Also, as noted earlier, you cannot use a local password file (such as /etc/passwd) for Linux systems that use shadow passwords. Note The following is sample output for the generate passwd utility that demonstrates the encryption of the clear-text password cisco123: linuxbox:~# generate_passwd Password to be encrypted: cisco123 egCv7fX.G5FgQ linuxbox:~# The following excerpt from Example 3-1 shows the password configuration for the three users spope, jkeith, and consultant1: user = spope { member = netadmin } user = jkeith { login = cleartext "securepassword123" } user = consultant1 { # this is encrypted DES password, manually generated by # program "generate_passwd" which is included with source tar password = des egCv7fX.G5FgQ } This example does not specify a password mechanism for the user spope . Hence, the TACACS+ Daemon uses the default authentication mechanism (using the /etc/passwd file) for user spope. For user jkeith, the password securepassword123 is specified in clear text, while for user consultant1, the DES-encrypted password is egCv7fX.G5FgQ. To set the password for local users in Linux, you can use the passwd username command. The following code shows the procedure for setting the password longpassword for user spope on a Linux machine: linuxbox:~# passwd spope Enter new UNIX password: longpassword Retype new UNIX password: longpassword passwd: password updated successfully Configuring Expiration DatesTo limit the age of a user account, specify the expiration date in the MMM DD YYYY format. Expiration applies to all password types except file passwords. The syntax is as follows: user = username { expires = "MMM DD YYYY" } The following excerpt from Example 3-1 shows the expiration date for user consultant1: user = consultant1 { expires = "Dec 15 2005" } In the absence of an expiration date for the user (or the group the user belongs to), the account will never expire. Configuring Service AuthorizationAuthorization allows the TACACS+ Daemon to permit or deny commands and services on a global or per-user basis. Authorization also provides the ability to modify commands and services on a per-user (or per-group) basis. By default, the TACACS+ Daemon denies authorization for all services, including the exec service. You must explicitly authorize each service for every user (or group). The default service authorization is specified at the group level and is applied to all members of the group. However, to provide tighter control for a single user, you can also declare a service authorization for each user under the user profile. For groups, the syntax is as follows: group = group-name { default service = permit attribute-1 = value { atribute-2 = value . . . } } For users, the syntax is as follows: user = user-name { default service = permit attribute-1 = value { atribute-2 = value . . . } } The default service = permit command must always be the first entry within the list of attributes. The following excerpt from Example 3-1 shows the commands that configure default authorization for the netadmin and regularusers groups: group = netadmin { default service = permit service = exec { priv-lvl = 15 } } group = regularusers { default service = deny service = exec { priv-lvl = 1 } } The service = exec command adds an exec prompt (better known as the command shell) as the authorized service that is available to the group. The priv-lvl = n command sets the privilege level for the command shell. Note that n can be any integer between 0 and 15. Setting the privilege level to 15 (the highest privilege level) authorizes the group members to run all the commands. The regularusers group members can only run commands that have a privilege level of 1. Note The commands available within the enable mode of Cisco IOS, CatOS, and PIX CLI are at privilege level 15. For more information on privilege levels, visit the "Understanding Privilege Level" page at the following URL:
Configuring Command AuthorizationThe commands entered at the exec prompt of a Cisco device can be authorized on a per-user or per-group basis. This is done by specifying a list of egrep-style regular expressions to match command arguments along with the deny or permit option on the TACACS+ Daemon. By default, the TACACS+ Daemon denies authorization for any command. The syntax for configuring command authorization is as follows: cmd = command { permit arguments deny arguments } The following excerpt from Example 3-1 shows the command authorization for user jkeith. The user is authorized to run the show commands. The permit .* entry authorizes all the arguments of the show command. The exit command allows the user to exit the session. Also, note the entry authorizing the telnet command. The permit 192\.168\.1\.[0-9]+ statement authorizes the user to Telnet to any address starting with 192.168.1. The subsequent deny .* statement prevents the user from Telnetting to any other address. The excerpt is as follows: user = jkeith { #... output suppressed for clarity cmd = show { permit .* } cmd = exit { permit .* } cmd = telnet { permit 192\.168\.1\.[0-9]+ deny .* } } The TACACS+ Daemon also provides the autocommand feature. This feature automatically instructs the IOS to execute a command after successful user authentication and prevents the user (or the group) from running any other command. After the autocmd command is executed, the user session automatically terminates. You must define autocommand after configuring the service authorization. The syntax is as follows: service = exec { autocmd = "command with argument" } The following excerpt from Example 3-1 shows the autocommand configuration for user consultant1. Before declaring the autocommand, the user must be authorized for the exec shell. The autocommand arguments are specified within the quotation marks. After user consultant1 successfully logs in to a router (preconfigured to use the TACACS+ Daemon for AAA), the show ip interface brief command runs automatically and ends the user session. This particular example is handy for selectively allowing remote users to log in to routers and determine the status of the LAN/WAN interfaces. The excerpt is as follows: user = consultant1 { # output suppressed for clarity service = exec { autocmd = "show ip interface brief" } } Note the absence of service authorization parameters, such as the exec service and privilege levels, for consultant1. You do not need to define service authorization when configuring autocommand. Configuring AccountingYou can enable accounting on the TACACS+ Daemon through the accounting file = log-file-on-the-linux-machine command. By specifying the accounting file, the TACACS+ Daemon records all the accounting file logins, using plain-text format. The command is configured at the top level of the configuration file. The following excerpt from Example 3-1 shows the location of the accounting log file: accounting file = /var/log/tac.log The TACACS+ Daemon records all the accounting logins in the /var/log/tac.log file. You can view the contents of the log file using any text editor (such as vi) or using built-in Linux commands (such as cat, tail, head, grep, and so on). Verifying the Configuration FileNow that the file has been created, it should be verified for syntax errors. The tac_plus executable file provides the verification functionality through the -P flag. The configuration file is specified using the -C flag. The command syntax is tac_plus -P -C config_file. Use the following syntax to verify the tacacs.conf file created in Example 3-1: linuxbox:/usr/local/bin# tac_plus -P -C /etc/tac-plus/tacacs.conf Edit the tacacs_config.txt file to remove errors that were encountered during the verification process. Starting the TACACS+ DaemonFollowing the successful verification of the configuration file, the TACACS+ Daemon is ready to be started. The command syntax is tac_plus -C config _ file -d 248. The following syntax is used to start the daemon with the configuration file tacacs_config.txt: linuxbox:/usr/local/bin#tac_plus -C /etc/tac-plus/tacacs.conf -d 248 The -d 248 flag generates debugging output in the var/tmp/tac_plus.log file. For debug messages with more details, specify a higher value in the - d flag. The possible values are listed in Table 3-2.
You can add each value for the desired level of debugging. For example, to view authorization and authentication messages together, you should specify the -d 24 flag (that is, 8 + 16 = 24). To verify that the TACACS+ Daemon has started, use the ps -f -C tac_plus command. The output of the ps command shows details such as the USERID, process identification (PID), time, and command used to start the process. Note that ps is a Linux system command that displays a snapshot of the current processes. The -f flag shows the full (detailed) output, whereas the -C tac_plus flag shows the processes started by the tac_plus command. The PID is useful for stopping the TACACS+ Daemon, using the kill -9 PID command, as follows: linuxbox:~# ps -f -C tac_plus UID PID PPID C STIME TTY TIME CMD tacacs 22840 1 0 01:07 ttyp0 00:00:00 /usr/sbin/tac_plus -C /etc/tac - plus/tacacs.conf -d 248 linuxbox:~# kill -9 22840 Note that you must stop and restart the daemon after making changes to the configuration file; otherwise, the changes do not take effect. Tip In Debian Linux, you can also use the /etc/init.d/tac-plus restart command to restart the TACACS+ Daemon. You can also use the netstat -a | grep tacacs command to verify that the Linux machine is listening on the TACACS+ port, as follows: linuxbox:~# netstat -a | grep tacacs tcp 0 0 *:tacacs *:* LISTEN Viewing Debug MessagesThe debug messages generated by the TACACS+ Daemon are logged in the /var/tmp/ tac_plus.log file. These messages can be viewed by using the tail command. The debug messages provide information regarding authentication, authorization, and accounting activities between the TACACS+ Daemon and the TACACS+ Client. The debug logs are not only useful for troubleshooting but are also helpful in creating various reports. As mentioned in the previous section, the TACACS+ Daemon, running at the debug level of 248, logs every authentication and authorization attempt. A successful login attempt is reported as login query for user ... accepted, whereas a failed attempt is reported as login query for user ... rejected. By using the Linux grep command, you can parse the TACACS+ Daemon log file to create reports of successful and failed login attempts. To view successful login attempts, use the Linux cat command in conjunction with the grep command to capture line entries that contain the word accepted, as shown in Example 3-2. Example 3-2. Report of Successful Login Attempts linuxbox:~# cat /var/tmp/tac_plus.log | grep accepted Sun Mar 20 22:49:28 2005 [2774]: login query for 'spope' tty1 from 192.168.0.10 accepted Sun Mar 20 22:50:02 2005 [2804]: login query for 'spope' tty1 from 192.168.0.10 accepted Sun Mar 20 23:20:49 2005 [3200]: login query for 'spope' tty2 from 192.168.0.10 accepted Sun Mar 20 23:21:02 2005 [3214]: login query for 'consultant1' tty2 from 192.168.0.10 accepted Sun Mar 20 23:21:17 2005 [3222]: login query for 'jkeith' tty2 from 192.168.0.10 accepted Sun Mar 20 23:22:08 2005 [3232]: login query for 'spope' tty2 from 192.168.0.10 accepted Sun Mar 20 23:34:13 2005 [3412]: login query for 'jkeith' tty1 from 192.168.0.10 accepted Sun Mar 20 23:36:22 2005 [3463]: login query for 'jkeith' tty2 from 192.168.0.10 accepted To limit the output of the report shown in Example 3-2, you can use the tail command. The syntax is cat /var/tmp/tac_plus.log | grep accepted | tail -n 5. The -n 5 option displays the last five entries. Similarly, to view failed attempts, parse the log file for the word rejected. The command is cat /var/tmp/tac_plus.log | grep rejected. Additional Configuration TemplatesThe following sections describe two additional sample templates for the TACACS+ Daemon configuration file. Configuring Unknown UsersIn the case of a large number of users, it is not practical to list every user within the configuration file. Moreover, Netadmins might prefer to use the usernames that are already defined on the local Linux machine. In such cases, you can use the template listed in Example 3-3. The user = DEFAULT entry instructs the TACACS+ Daemon to include all the users that are already defined on the local Linux machine. You must also configure the TACACS+ Daemon to use the /etc/passwd file to authenticate unknown users. The authorization for all the unknown users is controlled by the contents of the user = DEFAULT entry. In Example 3-3, the default authorization permits all the local users to use the exec shell with privilege level 15. Example 3-3. Configuring Unlisted Users # Specify the default authentication default authentication = file /etc/passwd # Users not listed in the file user = DEFAULT { default service = permit service = exec { priv-lvl = 15 } } Configuring Session TimeoutThe TACACS+ Daemon provides the ability to configure idle timeout and absolute timeout on a per-session basis. The timeout parameters are part of the service authorization parameters. Therefore, you must declare the timeout parameters within the service authorization configuration. You can configure the timeout parameters on a per-group or per-user basis. An idle timeout terminates a session that is idle after a period of no activity. The absolute timeout terminates the session irrespective of the activity status. If any of the timers are not specified, the TACACS+ Daemon uses the default value of 0, causing the session not to expire. In Example 3-4, the user ciscouser is configured with an idletime of 3 minutes and an absolute timeout of 30 minutes. The netadmin group is configured with an idletime of 25 minutes and an absolute timeout of 45 minutes. Example 3-4. Configuring the Session Timeout user = ciscouser { login = cleartext cisco123 service = exec { # disconnect, if user idle for 3 minutes idletime = 3 # disconnect, the user after 30 minutes timeout = 30 } group = netadmin { service = exec { # disconnect the group-members, if idle for 25 minutes idletime = 25 # disconnect the group-members, after 45 minutes timeout = 45 } Tip The Cisco website provides a good example of controlling access to IOS devices by using privilege levels and the TACACS+ Daemon. You can find the document "How to Assign Privilege Levels with TACACS+ and RADIUS" at the following URL:
Configuring Cisco Routers for TACACS+Cisco IOS devices (routers and switches) conform to the TACACS+ protocol and provide built-in TACACS+ Client functionality within the IOS code. However, by default, TACACS+ features are not enabled on IOS devices. To control access to IOS devices, you must not only configure the devices for TACACS+ but also deploy a TACACS+ Server. While previous sections cover the topic of deploying a TACACS+ Server, the following sections discuss details regarding TACACS+ Client functionality on Cisco IOS-based devices such as routers and Catalyst switches. TACACS+ configuration on an IOS-based device can be categorized into the following steps:
Step 1: Preparing the IOS Device for AAATo prepare an IOS device for AAA, you must use the commands shown in Table 3-3. The global configuration mode commands listed in Table 3-3 create a local user, enable AAA, and configure the TACACS+ Client on the IOS device. These commands are mandatory for configuring authentication, authorization, and accounting on the IOS devices.
Note IOS CLI Modes: You use the command-line interface (CLI) to access Cisco IOS Software. When you log in to the CLI, you are in user EXEC mode. User EXEC mode contains only a limited subset of commands. To have access to all commands, you must enter privileged EXEC mode, normally by using a password. From privileged EXEC mode, you can enter global configuration mode by using the configure terminal command. Global configuration mode allows you to make changes to the running configuration. From global configuration mode, you can enter interface configuration mode and a variety of other modes, such as protocol-specific modes. The router prompt Router(config)# indicates that you are in global configuration mode. Example 3-5 shows the IOS device configuration session for enabling AAA. Example 3-5. Preparing the IOS Device for AAAc:\windows\system32> telnet 192.168.0.10 User Access Verification Password: Dallas-Router>enable Password: Dallas-Router# Dallas-Router#config terminal Enter configuration commands, one per line. End with CNTL/Z. Dallas-Router(config)#username admin password s3curepassword Dallas-Router(config)#username admin privilege 15 Dallas-Router(config)#aaa new-model Dallas-Router(config)#tacacs-server host 192.168.0.30 Dallas-Router(config)#tacacs-server key VerYs3cr3taqskey Dallas-Router(config)#exit Dallas-Router# Step 2: Configuring AuthenticationAfter defining the TACACS+ Server and encryption key in Step 1, you must configure the login authentication. The login authentication is configured by creating a list of authentication methods. The list contains various authentication mechanisms, such as TACACS+ Server, local username database, and enable password. To configure the login authentication, use the commands shown in Table 3-4.
Based on the commands listed in Table 3-4, the syntax to configure login authentication is as follows: aaa authentication login default group tacacs+ local enable This command creates a default authentication list for all login authentications if no other list is specified. When a user tries to log in, the list first contacts a TACACS+ Server to validate the username and password. If no server is found or the TACACS+ Server returns an error, the list will then use the local username and password. If the local username is not defined, the list prompts for enable password. Step 3: Configuring AuthorizationAAA authorization enables you to set parameters that restrict a user's access to the network. TACACS+ authorization can be configured for commands, network connections, and EXEC sessions. Table 3-5 provides the command for configuring authorization on IOS devices.
Authorization is now configured for the exec shell and commands at privilege level 0, 1, and 15. Also, the default list first looks for the TACACS+ Server. If no server is found, TACACS+ returns an error and AAA tries to use the local list. If the local list is not defined, no authorization is performed. The list is shown in Example 3-6. Example 3-6. Configuring the IOS Device for Authorizationaaa authorization exec default group tacacs+ local none aaa authorization commands 0 default group tacacs+ local none aaa authorization commands 1 default group tacacs+ local none aaa authorization commands 15 default group tacacs+ local none Step 4: Configuring AccountingAAA accounting enables you to track the services that users are accessing as well as the amount of network resources they are consuming. The accounting can be configured using the commands shown in Table 3-6.
Accounting is now configured on the IOS device, as shown in Example 3-7, for logging all the commands entered by the authenticated user. Three separate entries are created for the three privilege levels specified during authorization. Example 3-7. Configuring the IOS Device for Accountingaaa accounting exec default start-stop group tacacs+ aaa accounting commands 0 default start-stop group tacacs+ aaa accounting commands 1 default start-stop group tacacs+ aaa accounting commands 15 default start-stop group tacacs+ The Cisco IOS device is now ready to be accessed using the username and password defined in the TACACS+ Server. Example 3-8 shows the complete configuration of an IOS device according to the discussion in preceding sections. Example 3-8. IOS Device with AAA ConfigurationDallas-Router# show running-config ! - - - Output truncated - - - ! Enable AAA aaa new-model ! Configure default login authentication using ! TACACS+,local database and enable password aaa authentication login default group tacacs+ local enable ! Configure service authorization for exec shell aaa authorization exec default group tacacs+ local none ! Configure command authorization for commands with privilege level 0 aaa authorization commands 0 default group tacacs+ local none ! Configure command authorization for commands with privilege level 1 aaa authorization commands 1 default group tacacs+ local none ! Configure command authorization for commands with privilege level 15 aaa authorization commands 15 default group tacacs+ local none ! Configure service accounting for exec shell aaa accounting exec default start-stop group tacacs+ ! Configure command accounting for commands with privilege level 0 aaa accounting commands 0 default start-stop group tacacs+ ! Configure command accounting for commands with privilege level 1 aaa accounting commands 1 default start-stop group tacacs+ ! Configure command accounting for commands with privilege level 15 aaa accounting commands 15 default start-stop group tacacs+ ! enable password 7 03075218050070 ! Configure local username username admin privilege 15 password 0 s3curepassword ! interface Ethernet0 ip address 192.168.0.10 255.255.255.0 ! interface Serial0 ip address 192.168.1.1 255.255.255.252 ! ip classless ip route 0.0.0.0 0.0.0.0 192.168.0.1 ip route 192.168.2.0 255.255.255.0 192.168.1.2 ! ! Define the TACACS+ server tacacs-server host 192.168.0.30 ! Define the TACACS+ key tacacs-server key VerYs3cr3taqskey ! line con 0 line vty 0 2 password 7 030752180500 line vty 3 4 password 7 13061E010803 ! end Configuring a Cisco Switch for TACACS+Similar to IOS, Cisco CatOS (the Cisco Catalyst operating system) also conforms to the TACACS+ protocol and provides built-in TACACS+ Client functionality within the CatOS code. Also, by default, TACACS+ features are not enabled on CatOS switches. To control access to CatOS switches, you must not only configure the switches for TACACS+ but also deploy a TACACS+ Server. While the TACACS+ Server is discussed in the section "Deploying a Linux-Based TACACS+ Server," earlier in this chapter, the following sections discuss TACACS+ Client functionality on Cisco CatOS switches. Note that Cisco switches use both the IOS and CatOS. Switches with IOS (also called native OS) can be configured as explained in the section "Configuring Cisco Routers for TACACS+," earlier in this chapter. The steps involved in configuring a Cisco switch for TACACS+ are as follows:
Step 1: Preparing the Switch for AAATo prepare the switch to use AAA, use the privileged-mode commands shown in Table 3-7.
Although not needed for AAA, it is good practice to configure the login and enable password on the switch for added security. Additionally, the enable password provides a last-resort option for the Netadmin to access the switch if the AAA server is down. Based on the commands discussed in Table 3-7, the AAA configuration for a CatOS switch is shown in Example 3-9. Example 3-9. Preparing a CatOS Switch for AAAConsole> (enable) set password Enter old password: cisco Enter new password: longsecret Retype new password: longsecret Password changed. USF-LM-MC2b> (enable)Console> (enable) set enablepass Enter old password: cisco123 Enter new password: s3curepassword Retype new password: s3curepassword Password changed. Console> (enable) set tacacs server 192.168.0.30 192.168.0.30 added to TACACS server table as primary server. Console> (enable) set tacacs key VerYs3cr3taqskey The tacacs key has been set to VerYs3cr3taqskey. Step 2: Configuring AuthenticationThe switches to use TACACS+ for authentication are configured in privileged mode, as listed in Table 3-8.
Based on the commands listed in Table 3-8, Example 3-10 shows configuring the switch for TACACS+ authentication. Example 3-10. Configuring a Switch for TACACS+ AuthenticationConsole> (enable) set authentication login tacacs enable tacacs login authentication set to enable for console and telnet session. Console> (enable) set authentication enable tacacs enable tacacs enable authentication set to enable for console and telnet session. Step 3: Configuring AuthorizationTACACS+ authorization is enabled on a switch in privileged mode using the commands shown in Table 3-9.
To control access to a switch, you must enable TACACS+ authorization for the exec shell, enable mode, and the commands entered by the authenticated users. Moreover, you must apply authorization on both console and Telnet connection attempts. Example 3-11 shows the configuration procedure for enabling authorization on a CatOS switch. Example 3-11. Configuring a Switch for TACACS+ AuthorizationConsole> (enable) set authorization exec enable tacacs+ if-authenticated both Successfully enabled enable authorization. Console> (enable) set authorization enable enable tacacs+ if-authenticated both Successfully enabled enable authorization. Console> (enable) set authorization commands enable config tacacs+ if-authenticated both Successfully enabled commands authorization. The configuration in Example 3-11 specifies TACACS+ as the primary authorization option. If the TACACS+ Server is unavailable, the fallback option (if-authenticated) authorizes all authenticated users. Without the fallback option, access to the switch is denied during TACACS+ Server outage. Step 4: Configuring AccountingAccounting is enabled on a switch in privileged mode using the commands shown in Table 3-10.
Based on the commands listed in Table 3-10, Example 3-12 shows the switch configuration for accounting. The configuration specifies the switch to log all the exec events and to log all the commands run by authenticated users. Example 3-12. Configuring a Switch for TACACS+ AccountingConsole> (enable) set accounting exec enable start-stop tacacs+ Accounting set to enable for exec events in start-stop mode. Console> (enable) set accounting commands enable all start-stop tacacs+ Accounting set to enable for commands-all events in start-stop mode. The Cisco switch (with CatOS) is now ready to be accessed using the username and password defined in the TACACS+ Server. Example 3-13 lists the TACACS+-based AAA configuration for a CatOS-based switch. Example 3-13. Switch Configuration for a TACACS+-Based AAAset tacacs server 192.168.0.30 set tacacs key VerYs3cr3taqskey set authentication login tacacs enable set authentication enable tacacs enable set authorization exec enable tacacs+ if-authenticated both set authorization enable enable tacacs+ if-authenticated both set authorization commands enable config tacacs+ if-authenticated both set accounting exec enable start-stop tacacs+ set accounting commands enable all start-stop tacacs+ Configuring Cisco PIX Firewalls for TACACS+Firewalls provide network security and are an integrated part of modern networks. Cisco offers a range of firewall appliances called PIX Firewalls, which use a proprietary operating system. Similar to Cisco routers and switches, you can also implement AAA functionality on a PIX Firewall. The PIX operating system can act as a AAA Client using both TACACS+ and RADIUS protocols. In addition, PIX can also use AAA to authenticate users who are trying to access network resources through the firewall. But, in comparison with the AAA implementation on IOS devices, PIX offers limited AAA functionality for controlling console (or Telnet) access to the firewall itself. This discussion is limited to securing console and Telnet access to the firewall. To control access to the PIX Firewall using the TACACS+ protocol, you must not only configure the firewall for TACACS+ but also deploy a TACACS+ Server. While the TACACS+ server is discussed in the section "Deploying a Linux-Based TACACS+ Server," earlier in this chapter, this section discusses TACACS+ Client functionality on Cisco PIX Firewalls. Table 3-11 lists the commands for configuring a TACACS+ Client over a PIX Firewall.
Based on the commands listed in Table 3-11, Example 3-14 shows the PIX Firewall configuration for authentication. The TACACS+ Server details are grouped under the tag MYAAA and are then applied to authenticate access to the firewall console through Telnet and the SSH console. You can choose any arbitrary text instead of the string MYAAA for grouping the AAA commands on the PIX Firewall. Example 3-14. Configuring the PIX Firewall for Authenticationc:\windows\system32>telnet 192.168.0.20 User Access Verification Password: Type help or '?' for a list of available commands. Dallas-Firewall> enable Password: Dallas-Firewall# config terminal Dallas-Firewall(config)# aaa-server MYAAA protocol tacacs+ Dallas-Firewall(config)# aaa-server MYAAA (inside) host 192.168.0.30 VerYs3cr3taqskey Dallas-Firewall(config)# aaa authentication ssh console MYAAA Dallas-Firewall(config)# aaa authentication telnet console MYAAA Dallas-Firewall(config)# exit The PIX Firewall is now ready to be accessed using the username and password defined in the TACACS+ Server. Recalling from the TACACS+ configuration in Example 3-1, the following username and password combinations should be able to log in into the PIX:
Tip The PIX Firewall provides back-door access to prevent a lockout if the TACACS+ Server is down. In such cases, use the following combination to access the PIX:
Caution Unlike the IOS AAA feature set, the PIX does not offer local authentication as a fallback feature. Hence, it is good administrative practice to configure the serial console of the PIX for local authentication. This avoids denial to the serial console because of problems with the AAA server or wrong configurations. The suggested configuration on the PIX is as follows: username admin password somepassword privilege 15 username helpdesk password someothepassword privilege 1 aaa-server LOCAL protocol local aaa authentication serial console LOCAL Configuring a Cisco VPN Concentrator for TACACS+A VPN, or virtual private network, consists of remote private networks connected through the Internet. In comparison with traditional leased lines, VPNs are cheaper because VPNs use the public network (Internet). A VPN concentrator, such as the Cisco VPN 3000 appliance, is the device used to connect remote users or networks through the Internet. Cisco VPN 3000 concentrators use proprietary operating systems with a web-based GUI for configuration and administration. The administrative console of a VPN 3000 concentrator provides the GUI for configuring and monitoring the concentrator and is accessible through any Internet browser. Beginning with VPN 3000 Concentrator Release 3.0, you can implement a TACACS+-based AAA to control access to the administrative console. However, unlike the IOS devices, the VPN 3000 concentrator only supports basic authentication services and does not support authorization and accounting. To control access to VPN 3000 concentrators using the TACACS+ protocol, you must not only configure the concentrator for TACACS+ but also deploy a TACACS+ Server. While the TACACS+ Server is discussed in the section "Deploying a Linux-Based TACACS+ Server," earlier in this chapter, this section discusses TACACS+ Client functionality on Cisco VPN 3000 concentrators. To configure authentication on a concentrator, follow these steps:
The VPN concentrator is now ready to be accessed using the username and password defined in the TACACS+ Server. Based on the TACACS+ configuration file in Example 3-1, the username spope should be able to log in to the concentrator using the password longpassword. Caution After you configure TACACS+, make sure that you test authentication before you log out. An improper configuration of TACACS+ can lock you out. If you are locked out, a serial port login (using the locally defined username and password) is required to disable TACACS+ and rectify the problem. Note that regardless of the TACACS+ configuration, the concentrator always uses the locally defined username and password for the serial port connection. If you change the default username and password combination, (admin and admin, respectively), be sure to test the new combination before configuring the TACACS+-based authentication. |
EAN: 2147483647
Pages: 106
- Integration Strategies and Tactics for Information Technology Governance
- Linking the IT Balanced Scorecard to the Business Objectives at a Major Canadian Financial Group
- A View on Knowledge Management: Utilizing a Balanced Scorecard Methodology for Analyzing Knowledge Metrics
- Measuring ROI in E-Commerce Applications: Analysis to Action
- Technical Issues Related to IT Governance Tactics: Product Metrics, Measurements and Process Control