Authentication, Authorization, and Accounting Protocols (AAA)

Certification Zone - Tutorial
Page 1 of 45
Tutorial
Authentication, Authorization, and Accounting Protocols (AAA)

by David Wolsefer Introduction The Products Security Architectural Concepts Two-Factor Authentication How AAA Improves the Scalability of Authentication Authorization/Credentialing Accounting/Logging/Audit Digital signatures PKI The Protocols Relevant Protocol Mechanisms Method Lists Terminal Access Controller Access Control System Plus (Tacacs+) Brief historical overview Operation Relevant Packet/Traffic Analysis Remote Authentication Dial In User Service (Radius) Brief historical overview Operation Relevant Packet/Traffic Analysis Kerberos Brief historical overview Operation Relevant Packet/Traffic Analysis Configuring the CiscoSecure ACS Server Windows
Adding a Network Device as AAA Client Using Tacacs accounting
Unix Configuring Tacacs IOS Tacacs Configuration Task List CatOS PIX OS Example - Authentication and Authorization Commands VPN Concentrator (3005, 3015, 3030, etc.) Configuring Radius IOS Radius Configuration Task List CatOS PIX OS Configuring Radius Authorization Configuring Kerberos IOS CatOS PIXOS
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 2 of 45
Conclusion References
Introduction
Imagine that you are the Chief Security Officer for a large ISP that has thousands of routers. You have just found out that a key employee is leaving the company for another opportunity. This employee has access to every router and switch in the company, and the departure is going to present a real security problem. How can we possibly go into every router and switch and manually change the passwords? It will take days. The answer is, of course, that we can't. Manually changing the passwords on every router and switch is totally impractical. Sure, we have all logged into routers and switches and entered either our username and password or a user level and enable level password in a lab situation, but this is not scalable for large deployments. Luckily, there are more sophisticated methods available for controlling access to network devices that provide much greater security and flexibility than simple usernames and passwords configured locally on each router, switch, firewall or other networking device. The preferred method for controlling access to networking devices in a large deployment is to use an Authentication, Authorization, and Accounting or AAA (pronounced "triple A") protocol such as Radius, Tacacs, or Kerberos. You may have used AAA in the past and not even been aware of it because AAA is not used just to control local access to networking devices. AAA is also used for many other applications. In the early days of the Internet, when most people dialed up their ISP using a modem for access, they probably used Radius during the PPP or SLIP login. Although Radius is frequently used for AAA of dial up and other remote access accounts, Cisco decided to develop another AAA system called Tacacs that is specifically designed to control access to common networking devices such as routers running IOS, switches running IOS and CatOS, PIX firewalls and more. The Unix community at MIT developed yet another AAA system called Kerberos and uses it extensively on the MIT campus. Today, we have taken the AAA concept and extended it even further by using tokens. A practical example is to use Tacacs with an RSA SecurID one time password token for even higher security, but just what does AAA do for us? AAA lets us identify exactly who is logged into a given network device. This means that one of the major functions of AAA is to use a client-server model where the networking devices such as routers, switches, firewalls, etc. are the clients, and the server is the AAA protocol server, i.e., the Radius, Tacacs, or Kerberos server. AAA is then used to control access to these devices. Another major function of AAA is to control access to the network's resources (where resources refers to other users, servers, printers, or networking devices themselves) for remote access users (i.e., someone connecting via dial up access, ISDN, DSL, etc.). These two functions are the first "A" of triple A, authentication. The next "A" of triple A is authorization. With authorization, we can specifically authorize every command that a given user may enter. Note however, that not all AAA protocols provide all three parts of AAA. Kerberos, for example, only uses authentication. Finally, the third "A" in triple A is accounting. Sure, accounting can be used in the traditional sense such as for billing purposes by monitoring usage for dial up accounts, but "accounting" doesn't mean just billing. In a broader concept, accounting is used to make some user or process "accountable" for every action. Accounting provides, in essence, an audit trail of actions taken by a given user on a given device. The accounting database provides a valuable audit trail to catch unauthorized changes or access and can be used as an additional troubleshooting tool. For example, suppose that the day shift in a NOC performed a scheduled change on a router, but the night shift receives a trouble ticket for the same device. The night shift engineer can then check the accounting database and see exactly what changes were made on the router and if they were in accordance with the planned change or if a step was missed, etc. AAA is useful not just for console or telnet/secure shell (SSH) access to networking devices. In this era
Page 3 of 45
of VPNs, PSTN dialup access, and ISDN access, AAA can provide a more secure method of access beyond a simple username and password. AAA can even be used in situations where host applications check application logins. As a practical example of this, we recently deployed an SSL browser-based application where users must login and authenticate using an RSA SecurID. One logical question to ask is that although we know what AAA can do, just what are the limitations of AAA? Why don't we use AAA for everything? Although AAA is a very valuable security addition to the network, there are several limitations of AAA. One limitation is with Graphical User Interfaces (GUIs). Network devices that have GUIs may not be able to log every command like command line interface (CLI) devices can. You should remember that even though devices that use a GUI may not be capable of a full AAA deployment, they might be capable of at least authentication for administrator logins. A perfect example of this is the Cisco VPN concentrator. Another limitation is that not every Cisco device supports AAA. See Table 3 for an example of some devices that do not support AAA. For example, you may have a Local Director in your network. This older load balancer does not support AAA at all. Perhaps you have a CSS11050 load balancer. Unless you have the correct version of WebNS, you cannot configure Tacacs. Perhaps you have a firewall from another vendor such as a Nokia running CheckPoint. Since CheckPoint uses a GUI interface, you cannot get the same level of AAA support that you can get with a Cisco PIX firewall. This should bring up the question of just which Cisco devices support AAA. Again, the answer varies, but in general, anything running IOS, PIX OS, CatOS, certain versions of WebNS on the Cisco CSS load balancers, and VPN Concentrators will support AAA to some extent. This varies by component and must be checked. You should also be aware that not every device supports all three AAA protocols (Radius, Tacacs, and Kerberos). Keep in mind that you need to check the current Cisco exam blueprints to make sure of the relevance of each topic. In general, at the moment, Radius and Tacacs are present in the CCIE routing and switching exam blueprint, but Kerberos may not be. The CCIE Security exam blueprint, however, covers all three AAA protocols.
The Products
One of the reasons that I prefer equipment from Cisco is the tightly integrated support for the different networking components. It is simply much easier to build a network when you use routers, switches, firewalls, and load balancers from one vendor than to try to integrate equipment from multiple vendors such as Juniper routers with Foundry switches with F5 load balancers and Nokia/Checkpoint firewalls. One of the problems that you run into with multiple vendors is varying degrees of support for any given AAA protocol. It is difficult to deploy AAA in a network when some components support only Tacacs, but others support only Radius. Table 1 summarizes a list of Cisco equipment that supports AAA. This does not mean that these are the only Cisco products that support AAA, these are just the most common ones. Table 1. Products that use AAA Servers IOS Firewall Feature Set The only difference in configuring AAA with the Firewall Feature Set is that although there is no specific CBAC support for Kerberos, Radius, or Tacacs, because Context-based Access Control (CBAC) can support any UDP or TCP port, you may use CBAC to inspect AAA packets. Note: CBAC is generally used only on Internet-facing interfaces, so you wouldn't normally use it to inspect AAA packets.
CatOS Cisco Secure PIX Firewall VPN Concentrator Although the Cisco Secure PIX Firewall supports the authentication and authorization functions of AAA, as of PIX OS 6.3.3, auditing is not supported. The VPN concentrator can use AAA for authentication of the administrative users.
Table 2 presents some products that are AAA servers. There are many available choices for AAA servers including freeware, shareware productions, and commercial products from many different vendors.
Page 4 of 45
Table 2. Server Products Vendor Cisco Cisco Funk Software MIT Product CiscoSecure ACS for Windows CiscoSecure ACS for UNIX Steel-Belted Radius Kerberos (including Windows, MacOS, and Unix)
FreeRADIUS Server Project freeRadius (at http://www.freeradius.org/) Dialways Lucent Livingston DialWays v3.0 NaviRadius Livingston Radius
You should be aware that, for purposes of the CCIE lab, Cisco has stated that for the Routing and Switching exam, you will not be responsible for configuring CiscoSecure ACS. This is probably also true for the CCIE Security lab exam, but you should really check CCO for the latest information. This does not mean that there won't be a pre-configured CiscoSecure server available in the lab somewhere. Remember, anything in IOS is free game, so you could definitely be provided with the IP address of the CiscoSecure server, given the AAA key, and asked to configure a given device for AAA using a specified username/password from the AAA server. Table 3. End-of-sale and other Cisco products that do not use AAA servers Cisco Secure Policy This product has reached end-of-sale or end-of-life status; it cannot be Manager (formerly Cisco ordered and may no longer be supported. Cisco Secure Policy Manager Security Manager) has been replaced by Cisco Works VMS. Configuration of Cisco Works VMS is beyond the scope of this paper. Cisco Secure Intrusion Detection System (formerly NetRanger) Cisco Local Director Cisco Secure IDS does not support Tacacs.
The OS just doesn't support AAA
Security Architectural Concepts

Security depends, above all, on being able to assign accountability to every action affecting securityprotected information, always knowing what user accesses them. Many principles of security were first widely documented in the "Orange Book", the Trusted System Criteria developed by the National Security Agency. While somewhat dated, it is the first of many "Rainbow Books" that deal with different aspects of trusted systems. Authentication is the first step in making sure that only authorized users get access to "protected objects". Formally, an object is "A passive entity that contains or receives information. Access to an object potentially implies access to the information it contains. Examples of objects are: records, blocks, pages, segments, files, directories, directory trees, and programs, as well as bits, bytes, words, fields, processors, video displays, keyboards, clocks, printers, network nodes, etc." [OrangeBook 1985] A protected object provides coordinated access to shared data, through calls on its visible protected
Page 5 of 45
operations, which can be protected subprograms or protected entries. The Orange Book defines two levels of access control: "Discretionary Access Control - A means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control)." "Mandatory Access Control - A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity."
Two-Factor Authentication
Although simple passwords are easy to implement and use, they have security problems. For example, believe it or not, "Cisco" is one of the most common passwords used. Sure, passwords are easy to implement and use, but it is not easy to enforce good password discipline. All it takes to take advantage of password weaknesses is a sniffer and a user who uses an insecure protocol such as Telnet or FTP, and bingo, you have their password. For these reasons, recognizing that password systems can be weak, many companies have explored alternatives. Two-factor authentication is based on something you know (e.g., a password or PIN number) and something you have (e.g., a token card or other authenticator). This concept can be expanded further in that two-factor authentication is a purported userid, authenticated with at least one of something you know (e.g., a password), something you have (e.g., a token), or something you are (e.g., biometrics). Additionally, this can be strengthened with checks on where you are (access lists), time of attempts, etc. This approach provided a much more reliable level of user authentication and security than a simple password or other digital certificate scheme. Every time you go to the bank and use an ATM card, you are using two-factor authentication. Think about this practical example. You go to your ATM and insert your ATM card (the token) and then enter your PIN (something you know). Personally, I like to use an RSA SecurID token for two-factor authentication in conjunction with AAA. For more information on RSA SecurID, see the RSA Security website at http://www.rsasecurity.com/. A token can take many forms including challenge/response tokens, time-based tokens, end-user service tokens and one-time password tokens. Another alternative to a simple username/password system that some companies have explored is to use digital certificates. Depending on how they are implemented, digital certificates can provide varying degrees of security. For example, a digital certificate that is unprotected on a user's desktop does not provide strong assurance that the user presenting the certificate is in fact the person who is supposed to have the certificate. A digital certificate, however, that is present on a device controlled by a user such as smart card or other token device that can only be accessed after the user enters a PIN is a strong two-factor authentication solution. Just how does authentication work? Let's use a router running IOS. At its most basic, a user can telnet into a router and will simply be challenged for a password that an administrator has configured for the router. Here is an example.
Router1>telnet Router2 Trying Router2 (192.168.1.2)... Open User Access Verification Password: xxxxxxxx Router2>
We can get more sophisticated and login using not just a simple password, but a local username and password database that prompts you to make sure that you not only have a valid username, but a valid password as well. If you think about it, this is really an example of two-factor authentication at its simplest where the username is the first factor and the password is the second factor. Here is an
Page 6 of 45
example where I supply the username as part of the SSH command. Notice what happens when I enter the wrong password, then the correct password.
Router1>ssh 192.168.1.2 -l dwolsefer [email protected]'s password: Permission denied, please try again. [email protected]'s password: Router2>enable Password: Router2#
These systems work fine if you are in a small office or have only a single home router, but what happens when you are a large corporation or a service provider with hundreds or thousands of routers? It isn't practical to configure and maintain a local database of usernames and passwords on each device. It would take hundreds of usernames and passwords for one thing, with people constantly joining and leaving the company. You also don't want to maintain a different enable password for each device. How would you keep track of them? You certainly don't want to use the same password for each router, and you don't want to have to change the password every time someone joins or leaves the company either. So, just what is a scalable solution?
How AAA Improves the Scalability of Authentication

AAA services are usually implemented on specific servers. The general functions of these servers, which may be on the same platform, break into user identification and authentication, authorization (also called credentialing or granting of privileges) and accounting. Accounting might have been called auditing. AAA servers are also called Radius, Tacacs+ or Kerberos servers after the main families of protocols used for authentication and authorization. AAA servers typically interact with other types of servers as well as clients (e.g., on routers). Such other services include: syslog - the receiver for a variety of auditable events. DHCP - granting addresses after authentication. Many relationships are possible in address assignment in cooperation with AAA, including the AAA server acting as a proxy to DHCP, code that uses a DHCP server to support PPP address assignment using the IP Control Protocol, dynamic DNS, etc. Tokens - authentication servers that validate hardware security tokens such as the Security Dynamics ACE server for SecurID smart cards. A scalable solution is an authentication, authorization, and accounting (AAA) server such as Radius or Tacacs, but just how does AAA work? AAA uses a central or distributed database on a server(s) to keep track of users and their passwords for authentication. With AAA, you may have another database that specifically authorizes the commands that each user may use. Finally, you may have a third database to keep accounting records of each command entered, by whom, at what time, and on which systems. You don't have to use all three components of AAA and, in large implementations, you may even be able to host each separate function on a separate server. With these ideas in mind, let's take a look at how a typical AAA protocol might work. In this example, a user wants to SSH to a remote router and has a valid username and password. When the user tries to SSH to the router, the router checks with the AAA server, which has a remote
Page 7 of 45
database of usernames and matching passwords, to make sure that this user is authorized. This illustrates one of the advantages of AAA in a large environment. The database resides on an AAA server rather than locally on each router. If this user resigns tomorrow, all you have to do is disable the authorization at a central point rather than locally on every router.
Figure 1. Components using the AAA Server
Authorization/Credentialing
Once a user has been authenticated, then we know who they are. The next step in the process is to decide what the user is allowed to do based on that authentication. After all, we may want level 3 engineers to have enable access, but level 1 engineers to have access only to show commands. Perhaps we want to allow customers to view their own configurations with the show configuration command, but do not want them to be able to make any changes. We can use command authorization to decide just what level of access a given user should have for each networking device. IOS has privilege levels 0 through 15 to control which IOS commands the user can issue. A user with privilege level 0 cannot issue any commands, but a user with level 15 can issue any IOS command. You can set the privilege level for a given command either in the local database or by using a remote AAA server. For example, I like to change the privilege level of the clear line command for use on a terminal server where we want to limit the access that users have so that the users who only have level 1 access can still clear their hung sessions.
Page 8 of 45
privilege exec level 1 clear line

Suppose that you are new to a company and are given a username and password for a system and login, but you are not sure what privilege level you have. You can check by using the show privilege command. Here is an example:
router1>sh privilege Current privilege level is 1 router1>en Password: Router1# router1#show privilege Current privilege level is 15
Just how does authorization work with AAA? AAA determines which specific rights a given user has by associating attribute-value (AV) pairs, which define those rights with that appropriate user. As you can see, there are quite a few attributes. An external AAA server will then transmit the correct rights for the authenticated user back to the networking device.
router1#show aaa attributes

Table 4. AAA Attribute Table Type Attribute Name 1 2 3 4 5 6 7 8 9 10 11 12 ... 405 406 407 408 409 410 411 feature-op-time feature-id supp-svc-xfer-by String String String disc-cause-ext Acct-Status-Type acl auth-services addr addr-pool asyncmap Authentic autocmd Format Enum Enum Ulong Enum IPv4 Address String Ulong Enum String
autocmd_ipprompt String callback-dialstring callback-line String Ulong
faxrelay-start-time String faxrelay-stop-time vrf-id isakmp-phase1-id String String String
Page 9 of 45
412 413
isakmp-initator-ip isakmp-group-id
IPv4 Address String
Accounting/Logging/Audit
The final step in the AAA process is accounting. Accounting takes place once the user has passed the authentication and authorization phases. Accounting lets us keep better track of a user's activities by recording who logged in, when and for how long, how many bytes were transferred, and which commands were issued. You can view accounting information locally or on the central AAA security server. You can see local accounting information on a router by issuing the show accounting command. Here are a few examples:
termserver#show accounting Active Accounted actions on tty130, User user1 Priv 1 Task ID 539, EXEC Accounting record, 00:01:45 Elapsed task_id=539 start_time=1064194984 timezone=edt service=shell or router#show accounting Active Accounted actions on tty130, User user1 Priv 1 Task ID 555, EXEC Accounting record, 00:00:51 Elapsed task_id=555 start_time=1064195486 timezone=edt service=shell Overall Accounting Traffic Starts Stops Updates Exec 0 339 0 Network 0 0 0 Connect 0 0 0 Command 0 218 0 Rsrc-mgmt 0 0 0 System 0 0 0
Active 1 0 0 0 0 0
Drops 0 0 0 0 0 0
User creates:1554, frees:1552, Acctinfo mallocs:558, frees:556 Users freed with accounting unaccounted for: 0 Queue length: 1
Note: on newer versions of IOS, the command syntax has changed. Here is what you will see if this is the case:
router1#show accounting "show accounting" is no longer supported. Please use: "show aaa user all" instead
Accounting information can be very useful for several reasons. One reason is that an audit trail can be a valuable troubleshooting tool. For example, suppose that you work in a network operations center and just changed shifts. You get a call for a trouble ticket and realize that another engineer was working on the router in question on the previous shift. With accounting information, you can look at every command entered by the previous engineer and see what changes were made. This can help pinpoint the source of the problem and lead to a quicker resolution. Another reason is to enforce good discipline and proper change procedures. For example, without accounting, a user can go make changes at any time as long as they have the password. With accounting, however, a user will know that their activity will be tracked and thus stick to strict change procedures.
Page 10 of 45
The accounting information available locally is not as valuable as the accounting information available on the remote AAA server. Here is an example. Notice how the information is available for each user, the time and date the command was entered, what device the command was entered on and at what privilege level:
Figure 2. Components using the AAA Server
Digital signatures
Although we have already defined authentication in terms of Radius, Tacacs+, and Kerberos, we need to be aware of authentication in a broader sense. Strictly defined, authentication is the process through which one proves and verifies certain information. Sure, we may want to use authentication to verify the identity of a user, but there are other uses for authentication. Some examples of these other uses are to verify the origin of documents, the time and date documents were sent, and so on. We can use authentication so that participants in a transaction cannot later deny taking part in the transaction. We are used to seeing this in the form of a legal signature on paper documents in the presence of a notary, but there are also digital signatures. A digital signature is a cryptographic method through which many of these same things may be verified. Using both the document and the signer's private key to create a new piece of information creates the digital signature of a document. If you have ever used Phil Zimmerman's Pretty Good Privacy (PGP) software, you can see that this is typically created through the use of a hash function and
Page 11 of 45
a private signing function (encrypting with the signer's private key). Every day, people sign their names to letters, credit card receipts, and other documents, demonstrating they are in agreement with the contents. That is, they authenticate that they are in fact the sender or originator of the item. This allows others to verify that a particular message did indeed originate from the signer. However, this is not foolproof, since people can 'lift' signatures off one document and place them on another, thereby creating fraudulent documents. Written signatures are also vulnerable to forgery because it is possible to reproduce a signature on other documents as well as to alter documents after they have been signed. Digital signatures and hand-written signatures both rely on the fact that it is very hard to find two people with the same signature. People use public-key cryptography to compute digital signatures by associating something unique with each person. When public-key cryptography is used to encrypt a message, the sender encrypts the message with the public key of the intended recipient. When publickey cryptography is used to calculate a digital signature, the sender encrypts the "digital fingerprint" of the document with his or her own private key. Anyone with access to the public key of the signer may verify the signature.
PKI
You may have heard of PKI if you have configured an IPSec VPN or perhaps if you have used Pretty Good Privacy (PGP), but just what is PKI? PKI stands for Public Key Infrastructure (PKI). The PKI ensures that data communications are private and protected from tampering. PKI can be used to ensure the following: verification of the identity of the parties involved in an electronic transmission that no party involved in an electronic transaction can deny involvement in the transaction the integrity of electronic transmissions by making sure that they are unaltered during their trip between parties. that data can be transmitted securely by being encrypted for transmission so that no one but the correct parties can read the data even if the data is intercepted. If you use PGP, then you can see exactly how all these functions operate. For example, you do not have to encrypt data with PGP. You can just attach a digital signature so that someone will know that the data (such as an email) is definitely from you. You can; however, both encrypt and digitally sign a message or file as well. PKI makes this possible because with PKI, you can use a combination of public keys, cryptography, and digital signatures to meet these needs. This paper is not meant to go in depth on certificates or PKI and does assume that the reader has a basic knowledge of these topics. If you do not have that knowledge or wish to learn more, please see Annlee Hines' Securing Communications I Study Guide. The way this works is that each party generates two keys. One key is private and the other is public. You send out your public key to anyone you want to be able to encrypt data that will be sent to you. The other party then encrypts the data and sends it to you. Even though they can encrypt the data to be sent to you, only you can decrypt it because decryption requires your private key. You can see an example of a digital signature in the form of digital certificates that you get at certain web sites. For example, a given vendor might obtain a Certificate of Authority from a company such as VeriSign that guarantees that the certificate issued is genuine. You see this a lot with SSL during secure transactions.
The Protocols
Page 12 of 45
Relevant Protocol Mechanisms Method Lists

Before you can configure AAA in the form of Radius or Tacacs, you must master method lists. A method list is a list that defines the authentication methods used to authenticate a user, the authorization methods used for a user, and the accounting methods used for a user. Method lists are flexible, because you can designate alternate methods in case the first method is unusable. For example, you can write a method list that says use Tacacs unless the Tacacs server is unreachable. If the Tacacs server is unreachable, then use the local login username and password. This is a very important capability for backup reasons. Suppose that the circuit connecting your Tacacs server loses the local loop due to a trenching machine cutting the fiber. If you did not have the ability to fall back to another Tacacs server or use another authentication method, then you would be in trouble until the circuit was repaired because you would not be able to authenticate with the AAA server and thus would be unable to login to the devices using that Tacacs server for authentication. The way that method lists work with IOS is that the first method listed will be the first method tried. If that first method is unavailable or returns an error code, then IOS will fall back to the next method. Note: the next method is only tried if the first method does not work because the first method is unreachable or reporting an error. If the authentication fails at any point and either the AAA server or local username database has denied the user access, then no other authentication attempt will occur. You would only fall back to the next method in the list if the first method received an error from the AAA server or the AAA server was unavailable. This process continues until a listed authentication method works or the authentication method list is exhausted. If no authentication method works or the authentication method list is exhausted, then authentication fails. This means, for example, that if you have a method list that specifies using Tacacs first and then local authentication next that you do not get to try a local login if the Tacacs server returns a code indicating that authentication has failed. You only get to try the alternate method if the Tacacs server is not reachable or returning an error code, e.g., the Tacacs daemon was not running. The syntax of method lists is simple, but you should be aware of the subtle differences between named and default method lists. Use a named method list if you want to use a different method list for the same services as the default method list, but on a different interface, otherwise you can just use the default list. Default method lists simply use the word default as a listname keyword. You should also be aware that if you use a named method list, you must apply it to a given interface or it will not be used. Here is an example of the syntax:
aaa authentication service listname method1 method2 ... method_n service is one of the named predefined services. listname is either a user-defined character string or the keyword default; and the methods are lists of predefined options. Some other keywords are as follows:
Table 5. Method List Keywords if-needed local Authenticate only if the user is not already authenticated Use local username lookup
local-case Use case-sensitive local username lookup none Do not authenticate (be careful using this. You can lock yourself out of the router)
Authorization method lists use a similar syntax to authentication method lists:
aaa authorization service listname method1 method2 ... method_n
Page 13 of 45
Typical keywords for authorization are the same as for authentication, but services are usually either exec or network. The exec keyword is used to start an EXEC shell, used with scripted logins and TCP Clear. The network keyword is used to enable related network services, such as PPP. Finally, accounting method lists also use a similar syntax to authentication and authorization method lists:
aaa accounting service listname method1 method2 ... method_n

Again, the keywords are the same as for authentication and accounting, but the services are different. Typical services for accounting are: Table 6. Accounting Method List keywords ppp Enables ppp
enable Enables access at privilege level 15 login Enables login access, either through scripted login or telnet
With accounting, you also need to specify when to send accounting records to the AAA server. The available options are: Table 7. Accounting export options Startstop Stoponly Waitstop Send both start and stop records Send only stop records Same as for start-stop, but wait for the ACK of the start record before allowing the user session to proceed
You should be aware that there is another very useful accounting mode available, although it is not part of AAA. This method is known as NetFlow. It works in a fashion similar to AAA accounting in that NetFlow data is exported to a server. The key difference is that NetFlow accounts for different information than AAA accounting. NetFlow data is data that keeps track of data flows. This means that with NetFlow, you can keep track of the source IP of a data flow, the destination IP of a data flow, and the port and protocols used for the data flow. This information can be invaluable during DoS and other attacks. A detailed discussion of NetFlow is beyond the scope of this paper, but you should be aware that it exists. You can use the show aaa method-lists all command to find some more examples of possible method lists.
router1#show aaa method-lists all authen queue=AAA_ML_AUTHEN_LOGIN authen queue=AAA_ML_AUTHEN_ENABLE authen queue=AAA_ML_AUTHEN_PPP authen queue=AAA_ML_AUTHEN_SGBP authen queue=AAA_ML_AUTHEN_ARAP permanent lists name=Permanent Enable None valid=1 id=0 : ENABLE name=Permanent Enable valid=1 id=0 : ENABLE name=Permanent None valid=1 id=0 : NONE
NONE
Page 14 of 45
name=Permanent Local valid=1 id=0 : LOCAL author queue=AAA_ML_AUTHOR_SHELL author queue=AAA_ML_AUTHOR_NET author queue=AAA_ML_AUTHOR_CONN author queue=AAA_ML_AUTHOR_IPMOBILE author queue=AAA_ML_AUTHOR_COMMAND author queue=AAA_ML_AUTHOR_RM author queue=AAA_ML_AUTHOR_CONFIG author queue=AAA_ML_AUTHOR_AUTH_PROXY author queue=AAA_ML_AUTHOR_PREAUTH author queue=AAA_ML_AUTHOR_FLTSV permanent lists name=local-list valid=1 id=0 : LOCAL acct queue=AAA_ML_ACCT_SHELL acct queue=AAA_ML_ACCT_AUTH_PROXY acct queue=AAA_ML_ACCT_NET acct queue=AAA_ML_ACCT_CONN acct queue=AAA_ML_ACCT_SYSTEM acct queue=AAA_ML_ACCT_RESOURCE acct queue=AAA_ML_ACCT_RM acct queue=AAA_ML_ACCT_COMMAND permanent lists name=Permanent None valid=1 id=0 Action=NOT_SET :
Terminal Access Controller Access Control System Plus (Tacacs+) Brief historical overview
Tacacs is a term commonly used to refer to Tacacs+, but actually applies to Tacacs, Extended Tacacs, and Tacacs+. There was a historical development of the original protocol from just plain old Tacacs to Extended Tacacs to the present Tacacs+ version. Although there are some differences between the three versions, each will authenticate a user against a username/password combination in a database and permit/deny access based on the authentication results and access authorization. Cisco developed Tacacs to fix a number of the deficiencies of Radius. It is critical that you understand the major differences between Radius and Tacacs.
Operation
There are many different Tacacs servers out there, but the one I use most is CiscoSecure Access Control Server (CiscoSecure ACS), which supports both Radius and Tacacs+. Note: CiscoSecure ACS is available in both a Unix (Solaris) version and a Windows version. You will have to check specific versions to determine exact operating system requirements. In general, Tacacs has the following features: Table 8. Comparing TACACS and Radius Radius AAA Support Radius combines authentication and authorization into one server. These functions cannot be separated across different servers. Radius supports only IP. Tacacs Tacacs uses the AAA architecture and can separate the three AAA functions across different servers. Tacacs supports other protocols, such as AppleTalk, NetBIOS, and
Multiprotocol Support
Page 15 of 45
IPX. Packet Encryption Packet Delivery Transport Type Router Management Radius encrypts only the password in the access-request packet from the client to the server. UDP port 1812, UDP port 1813 is used for accounting. Radius does not allow users to control which commands can be executed on a router. Tacacs encrypts the entire body of the packet but leaves a standard Tacacs header. TCP port 49 Tacacs does allow control over which commands can be executed on a router.
The Figure below shows a typical Tacacs connection request (Authentication).
Figure 3. TACACS connection request When a Tacacs server authenticates a user, the following events occur: 1. When the TCP connection is established, the router contacts the Tacacs server to obtain a username prompt, which is then displayed to the user. The user enters a username and the router contacts the Tacacs server to obtain a password prompt. The router then displays the password prompt to the user, the user enters a password, and the password is sent to the Tacacs server. 2. The router eventually receives one of the following four responses from the Tacacs server: ACCEPT - The user is authenticated and service can begin. If the router is configured to require authorization, authorization will occur next.
Page 16 of 45
REJECT - The user has failed authentication. The user will be prompted to retry the login sequence again or may just be denied further access, depending on the particular Tacacs+ server in use. ERROR - An error occurred at some time during authentication. This can be either at the daemon or in the network connection between the daemon and the router. CONTINUE - The user is prompted for additional authentication information. 3. PPP PAP and CHAP logins are similar to ASCII logins, except that the username and password arrive at the NAS in a PAP or CHAP protocol packet instead of being typed in by the user, so the user is not prompted. 4. If authorization is configured, it will happen once the user has been authenticated. At this point, the router will contact the Tacacs server again and the Tacacs server will return an ACCEPT or REJECT authorization response. If an ACCEPT response is returned, the response will contain data in the form of attributes used to direct the EXEC or NETWORK session for that user. The packets exchanged between the router and the Tacacs server contain attribute-value pairs (AV pairs). The router sends Start packets and the Tacacs server responds with Response packets. The server can permit, deny, or modify commands requested by the end user. The data (that contains the full list of all username/password pairs) is stored in a local file defining what commands are permitted for each user. Possible services include the following: Telnet, rlogin, Point-to-Point Protocol (PPP), Serial Line Internet Protocol (SLIP), or EXEC services Connection parameters, including the host or client IP address, access list, and user timeouts In the sample Tacacs debug output below, we see this happening. Notice how the debug trace picks up with the PASS from the authentication phase then proceeds to the authorization phase. We can then see the user data transmitted for authorization and the AVs sent. Finally, the server returns an "authorization successful" message.
Sep 21 21:49:48.249 edt: AAA/AUTHEN (251567022): status = PASS Sep 21 21:49:48.249 edt: AAA/MEMORY: free_user (0x61566E64) user='NULL' ruser='NULL' port='tty130' rem_addr='172.16.1.1' authen_type=ASCII service=ENABLE priv=15 Sep 21 21:50:51.498 edt: AAA/MEMORY: free_user (0x61568D90) user='test' ruser='NULL' port='tty130' rem_addr='172.16.1.1' authen_type=ASCII service=LOGIN priv=1 Sep 21 21:50:54.130 edt: AAA: parse name=tty130 idb type=-1 tty=-1 Sep 21 21:50:54.130 edt: AAA: name=tty130 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=130 channel=0 Sep 21 21:50:54.130 edt: AAA/MEMORY: create_user (0x61566E64) user='NULL' ruser='NULL' ds0=0 port='tty130' rem_addr='172.16.1.1' authen_type=ASCII service=LOGIN priv=1 initial_task_id='0' Sep 21 21:51:10.490 edt: AAA/MEMORY: free_user_quiet (0x61566E64) user='test' ruser='NULL' port='tty130' rem_addr='172.16.1.1' authen_type=1 service=1 priv=1 Sep 21 21:51:10.490 edt: AAA: parse name=tty130 idb type=-1 tty=-1 Sep 21 21:51:10.490 edt: AAA: name=tty130 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=130 channel=0 Sep 21 21:51:10.490 edt: AAA/MEMORY: create_user (0x615632AC) user='NULL' ruser='NULL' ds0=0 port='tty130' rem_addr='172.16.1.1' authen_type=ASCII service=LOGIN priv=1 initial_task_id='0' Sep 21 21:51:26.582 edt: tty130 AAA/AUTHOR/EXEC (1739401331): Port='tty130' list='' service=EXEC
Page 17 of 45
Sep 21 21:51:26.582 edt: AAA/AUTHOR/EXEC: tty130 (1739401331) user='test' Sep 21 21:51:26.582 edt: tty130 AAA/AUTHOR/EXEC (1739401331): send AV service=shell Sep 21 21:51:26.582 edt: tty130 AAA/AUTHOR/EXEC (1739401331): send AV cmd* Sep 21 21:51:26.582 edt: tty130 AAA/AUTHOR/EXEC (1739401331): found list "default" Sep 21 21:51:26.582 edt: tty130 AAA/AUTHOR/EXEC (1739401331): Method=tacacs+ (tacacs+) Sep 21 21:51:26.862 edt: AAA/AUTHOR (1739401331): Post authorization status = PASS_ADD Sep 21 21:51:26.862 edt: AAA/AUTHOR/EXEC: Authorization successful
You may choose which components of AAA to implement; not all phases are always needed. Once authorization is complete, the next optional phase is accounting. Tacacs accounting provides an audit record of what commands were completed. When accounting is configured on the router, the router sends a record of commands entered to the Tacacs server, and the Tacacs server sends a response acknowledging the accounting record.
Relevant Packet/Traffic Analysis

Although there aren't that many commands to debug Tacacs, they are pretty powerful because you can see every step of the communication between the router and the Tacacs server. The first useful command is debug tacacs. Here is a complete debug Tacacs sequence showing the initial authentication communications, followed by the authorization and finally the accounting. This can be a very useful command for troubleshooting Tacacs. This debug trace was recorded as a user logged on to a router using Tacacs.
Router#debug tacacs Tacacs access control debugging is on

Here a user logs in at privilege level 1 with username "test" using the default method list with Tacacs+ as the first method tried.
Sep 21 21:49:16.829 edt: AAA/MEMORY: free_user (0x6157CDA0) user='test' ruser='NULL' port='tty130' rem_addr='172.16.1.1' authen_type=ASCII service=LOGIN priv=1 Sep 21 21:49:19.137 edt: AAA: parse name=tty130 idb type=-1 tty=-1 Sep 21 21:49:19.137 edt: AAA: name=tty130 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=130 channel=0 Sep 21 21:49:19.137 edt: AAA/MEMORY: create_user (0x61568D90) user='NULL' ruser='NULL' ds0=0 port='tty130' rem_addr='172.16.1.1' authen_type=ASCII service=LOGIN priv=1 initial_task_id='0' Sep 21 21:49:19.137 edt: AAA/AUTHEN/START (4128140750): port='tty130' list='' action=LOGIN service=LOGIN Sep 21 21:49:19.137 edt: AAA/AUTHEN/START (4128140750): using "default" list Sep 21 21:49:19.137 edt: AAA/AUTHEN/START (4128140750): Method=tacacs+ (tacacs+)
Here we can see the response from the Tacacs server requesting the username as indicated by "GETUSER" and then the password as indicated by "GETPASS". You can then see the router respond, followed by the Tacacs server's response that the user has been authenticated successfully. The communications from the Tacacs server are indicated by the "TAC+" and "AAA" indicates communications from the router.
Sep 21 21:49:19.137 edt: TAC+: send AUTHEN/START packet ver=192 id=4128140750 Sep 21 21:49:19.417 edt: TAC+: ver=192 id=4128140750 received
Page 18 of 45
AUTHEN status = GETUSER Sep 21 21:49:19.417 edt: AAA/AUTHEN (4128140750): status = GETUSER Sep 21 21:49:22.153 edt: AAA/AUTHEN/CONT (4128140750): continue_login (user='(undef)') Sep 21 21:49:22.153 edt: AAA/AUTHEN (4128140750): status = GETUSER Sep 21 21:49:22.153 edt: AAA/AUTHEN (4128140750): Method=tacacs+ (tacacs+) Sep 21 21:49:22.153 edt: TAC+: send AUTHEN/CONT packet id=4128140750 Sep 21 21:49:22.353 edt: TAC+: ver=192 id=4128140750 received AUTHEN status = GETPASS Sep 21 21:49:22.353 edt: AAA/AUTHEN (4128140750): status = GETPASS Sep 21 21:49:30.761 edt: AAA/AUTHEN/CONT (4128140750): continue_login (user='test') Sep 21 21:49:30.761 edt: AAA/AUTHEN (4128140750): status = GETPASS Sep 21 21:49:30.761 edt: AAA/AUTHEN (4128140750): Method=tacacs+ (tacacs+) Sep 21 21:49:30.761 edt: TAC+: send AUTHEN/CONT packet id=4128140750 Sep 21 21:49:33.061 edt: TAC+: ver=192 id=4128140750 received AUTHEN status = PASS Sep 21 21:49:33.061 edt: AAA/AUTHEN (4128140750): status = PASS Sep 21 21:49:33.341 edt: TAC+: (1469827943): received author response status = PASS_ADD Sep 21 21:49:35.929 edt: AAA/MEMORY: dup_user (0x615632AC) user='test' ruser='NULL' ds0=0 port='tty130' rem_addr='172.16.1.1' authen_type=ASCII service=ENABLE priv=15 source='AAA dup enable'
Once the authentication phase is complete, the next step is the authorization phase. You can see that for authorization, the router uses the "default" method list and is requesting the service "shell" using Tacacs+. You can also see that the authorization was successful as indicated by the "Post authorization status = PASS_ADD." Now the user is authorized at privilege level 15.
Sep 21 21:51:26.582 edt: tty130 AAA/AUTHOR/EXEC (1739401331): Port='tty130' list='' service=EXEC Sep 21 21:51:26.582 edt: AAA/AUTHOR/EXEC: tty130 (1739401331) user='test' Sep 21 21:51:26.582 edt: tty130 AAA/AUTHOR/EXEC (1739401331): send AV service=shell Sep 21 21:51:26.582 edt: tty130 AAA/AUTHOR/EXEC (1739401331): send AV cmd* Sep 21 21:51:26.582 edt: tty130 AAA/AUTHOR/EXEC (1739401331): found list "default" Sep 21 21:51:26.582 edt: tty130 AAA/AUTHOR/EXEC (1739401331): Method=tacacs+ (tacacs+) Sep 21 21:51:26.582 edt: AAA/AUTHOR/TAC+: (1739401331): user=test Sep 21 21:51:26.582 edt: AAA/AUTHOR/TAC+: (1739401331): send AV service=shell Sep 21 21:51:26.582 edt: AAA/AUTHOR/TAC+: (1739401331): send AV cmd* Sep 21 21:51:26.862 edt: AAA/AUTHOR (1739401331): Post authorization status = PASS_ADD Sep 21 21:51:26.862 edt: AAA/AUTHOR/EXEC: Authorization successful Sep 21 21:51:30.270 edt: AAA/MEMORY: free_user (0x615661BC) user='NULL' ruser='NULL' port='tty130' rem_addr='172.16.1.1' authen_type=ASCII service=ENABLE priv=15
Next, the router uses Tacacs for accounting using the "default" method list with Tacacs. You can see that a positive response is received from the Tacacs server to start accounting and that the user entered the show accounting command. You can see that the user's next command no debug all is sent to the accounting server to be recorded into the accounting database. Finally, you can see that accounting stops and the TCP connection is closed.
Sep 21 21:52:00.122 edt: AAA/ACCT: user test, acct type 3 (4029509403): Method=tacacs+ (tacacs+) Sep 21 21:52:00.402 edt: TAC+: (4029509403):
Page 19 of 45
received acct response status = SUCCESS Sep 21 21:52:18.598 edt: AAA/ACCT/CMD: User test, Port tty130, Priv 15: "show accounting <cr>" Sep 21 21:52:18.598 edt: AAA/ACCT/CMD: Found list "default" Sep 21 21:52:18.606 edt: AAA/ACCT: user test, acct type 3 (2680368157): Method=tacacs+ (tacacs+) Sep 21 21:52:18.886 edt: TAC+: (2680368157): received acct response status = SUCCESS Sep 21 21:53:45.207 edt: AAA/ACCT/CMD: User test, Port tty130, Priv 15: "no debug all <cr>" Sep 21 21:53:45.207 edt: AAA/ACCT/CMD: Found list "default" Sep 21 21:53:55.839 edt: TAC+: using previously set server 172.16.1.2 from group tacacs+ Sep 21 21:53:55.839 edt: TAC+: Opening TCP/IP to 172.16.1.2/49 timeout=5 Sep 21 21:53:55.919 edt: TAC+: Opened TCP/IP handle 0x615680B4 to 172.16.1.2/49 Sep 21 21:53:55.919 edt: TAC+: Opened 172.16.1.2 index=1 Sep 21 21:53:55.919 edt: TAC+: 172.16.1.2 (4141160261) ACCT/REQUEST/STOP queued Sep 21 21:53:56.119 edt: TAC+: (4141160261) ACCT/REQUEST/STOP processed Sep 21 21:53:56.119 edt: TAC+: (4141160261): received acct response status = SUCCESS Sep 21 21:53:56.119 edt: TAC+: Closing TCP/IP 0x615680B4 connection to 172.16.1.2/49
Some other useful debug commands are debug aaa authentication, debug aaa authorization, and debug aaa accounting. Here is some example output: In this sample output from the debug aaa authentication command, you can see an EXEC login that uses the "default" method list and the first method, Tacacs+, is displayed. The Tacacs server then sends a GETUSER request to prompt for the username and then a GETPASS request to prompt for the password. Next, you will see the PASS response to indicate a successful login. The number 1202654323 is the session ID, which is unique for each authentication. This session ID can be very helpful for troubleshooting when there are multiple authentication sessions occurring at the same time.
debug aaa authentication Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan 4 21:15:01.419 EST: AAA/AUTHEN/START (1202654323): port='tty130' list='' action=LOGIN service=LOGIN 4 21:15:01.419 EST: AAA/AUTHEN/START (1202654323): using "default" list 4 21:15:01.419 EST: AAA/AUTHEN/START (1202654323): Method=tacacs+ (tacacs+) 4 21:15:01.419 EST: TAC+: send AUTHEN/START packet ver=192 id=1202654323 4 21:15:01.699 EST: TAC+: ver=192 id=1202654323 received AUTHEN status = GETUSER 4 21:15:01.699 EST: AAA/AUTHEN (1202654323): status = GETUSER 4 21:15:04.023 EST: AAA/AUTHEN/CONT (1202654323): continue_login (user='(undef)') 4 21:15:04.023 EST: AAA/AUTHEN (1202654323): status = GETUSER 4 21:15:04.027 EST: AAA/AUTHEN (1202654323): Method=tacacs+ (tacacs+) 4 21:15:04.027 EST: TAC+: send AUTHEN/CONT packet id=1202654323 4 21:15:04.227 EST: TAC+: ver=192 id=1202654323 received AUTHEN status = GETPASS 4 21:15:04.227 EST: AAA/AUTHEN (1202654323): status = GETPASS 4 21:15:13.155 EST: AAA/AUTHEN/CONT (1202654323): continue_login (user='dwolsefer') 4 21:15:13.155 EST: AAA/AUTHEN (1202654323): status = GETPASS
Page 20 of 45
Jan Jan Jan Jan
4 21:15:13.155 EST: AAA/AUTHEN (1202654323): Method=tacacs+ (tacacs+) 4 21:15:13.155 EST: TAC+: send AUTHEN/CONT packet id=1202654323 4 21:15:15.455 EST: TAC+: ver=192 id=1202654323 received AUTHEN status = PASS 4 21:15:15.455 EST: AAA/AUTHEN (1202654323): status = PASS
The following is an example of the debug aaa authorization command. In this display, an EXEC authorization for user "dwolsefer" is performed. You can also see that the session number is 2116885857. Note that the username is authorized and that the next two lines' attribute-value (AV) pairs are also authorized. Next, you can see that the authorization method used is Tacacs+. The final line in the display indicates the status of the authorization process, which is a pass or successful in this case.
debug aaa authorization Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan 4 21:18:47.212 EST: tty130 AAA/AUTHOR/EXEC (2116885857): Port='tty130' list='' service=EXEC 4 21:18:47.212 EST: AAA/AUTHOR/EXEC: tty130 (2116885857) user='dwolsefer' 4 21:18:47.212 EST: tty130 AAA/AUTHOR/EXEC (2116885857): send AV service=shell 4 21:18:47.212 EST: tty130 AAA/AUTHOR/EXEC (2116885857): send AV cmd* 4 21:18:47.212 EST: tty130 AAA/AUTHOR/EXEC (2116885857): found list "default" 4 21:18:47.212 EST: tty130 AAA/AUTHOR/EXEC (2116885857): Method=tacacs+ (tacacs+) 4 21:18:47.212 EST: AAA/AUTHOR/TAC+: (2116885857): user=dwolsefer 4 21:18:47.212 EST: AAA/AUTHOR/TAC+: (2116885857): send AV service=shell 4 21:18:47.212 EST: AAA/AUTHOR/TAC+: (2116885857): send AV cmd* 4 21:18:47.492 EST: AAA/AUTHOR (2116885857): Post authorization status = PASS_ADD 4 21:18:47.492 EST: AAA/AUTHOR/EXEC: Authorization successful
The debug aaa accounting command is not as useful as the other two debug aaa commands. For more information about the accounting going on, you might be better off using the debug radius or debug tacacs specific commands instead. You can also use the show accounting command for more information.
debug aaa accounting Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan 4 21:22:12.938 EST: AAA/ACCT/CMD: User dwolsefer, Port tty130, Priv 15: "clear logging <cr>" 4 21:22:12.938 EST: AAA/ACCT/CMD: Found list "default" 4 21:22:12.938 EST: AAA/ACCT: user dwolsefer, acct type 3 (3915005986): Method=tacacs+ (tacacs+) 4 21:22:13.330 EST: TAC+: (3915005986): received acct response status = SUCCESS 4 21:22:16.038 EST: AAA/ACCT/ACCT_DISC: Found list "default" 4 21:22:16.038 EST: tty130 AAA/DISC: 1/"User Request" 4 21:22:16.038 EST: AAA/ACCT/ACCT_DISC: Found list "default" 4 21:22:16.038 EST: tty130 AAA/DISC/EXT: 1020/"User Request" 4 21:22:16.038 EST: AAA/ACCT/ACCT_DISC: Found list "default" 4 21:22:16.038 EST: tty130 AAA/DISC: 9/"NAS Error" 4 21:22:16.038 EST: AAA/ACCT/ACCT_DISC: Found list "default" 4 21:22:16.038 EST: tty130 AAA/DISC/EXT: 1002/"Unknown" 4 21:22:16.042 EST: AAA/ACCT: no attribute "elapsed_time" to replace, adding it 4 21:22:16.042 EST: AAA/ACCT/EXEC/STOP: cannot retrieve modem speed
Page 21 of 45
Jan
Jan Jan Jan
Jan Jan Jan
Jan Jan Jan
4 21:22:16.042 EST: AAA/ACCT/EXEC/STOP User dwolsefer, Port tty130: task_id=1071 start_time=1073269127 timezone=EST service=shell disc-cause=1 disc-cause-ext=1020 connect-progress=40 elapsed_time=209 nas-rx-speed=0 nas-tx-speed=0 4 21:22:16.046 EST: AAA/ACCT: user dwolsefer, acct type 0 (3564001228): Method=tacacs+ (tacacs+) 4 21:22:16.426 EST: TAC+: (3564001228): received acct response status = SUCCESS 4 21:22:16.426 EST: AAA/MEMORY: free_user (0x61564FC4) user='dwolsefer' ruser='NULL' port='tty130' rem_addr='192.168.1.1' authen_type=ASCII service=LOGIN priv=1 4 21:22:18.258 EST: AAA: parse name=tty130 idb type=-1 tty=-1 4 21:22:18.262 EST: AAA: name=tty130 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=130 channel=0 4 21:22:18.262 EST: AAA/MEMORY: create_user (0x6156468C) user='NULL' ruser='NULL' ds0=0 port='tty130' rem_addr='192.168.1.1' authen_type=ASCII service=LOGIN priv=1 initial_task_id='0' 4 21:22:34.282 EST: AAA/ACCT/EXEC/START User dwolsefer, port tty130 4 21:22:34.282 EST: AAA/ACCT/EXEC: Found list "default" 4 21:22:34.282 EST: AAA/ACCT/EXEC/START User dwolsefer, Port tty130, task_id=1078 start_time=1073269354 timezone=EST service=shell
Remote Authentication Dial In User Service (Radius) Brief historical overview

Radius began when a company called Livingston submitted a response to an RFI that was sent out by Merit, Inc. to meet the need for dial up authentication in Michigan. The response to the RFI was a description of Radius. Merit liked the solution description and awarded the contract to Livingston. If you have been around for a while, then you may very well remember using Livingston "Portmasters" for authentication in the days before high speed when almost everyone used a dial up ISP for Internet access. Merit bought and installed Livingston Portmasters and Radius server software (which Livingston included for free with the Portmaster hardware) for use in MichNet. "At about the same time, the Fall of 1992, a NAS requirements (NASREQ) working group was formed in the IETF. At the April 1994 IETF, Steve Willens and Carl Rigney (also with Livingston) submitted Radius as an Internet Draft to the NASREQ working group. They also offered open access to the Radius server source code developed by Livingston. This code is the Livingston Radius Server, and is the basis for many subsequent Radius servers. There was a fair amount of discussion at the IETF about whether Radius was appropriate as a standard. There were concerns about security and about whether this was even an appropriate protocol to be dealt with by IETF. Even with these concerns, after the Radius protocol became available as an Internet Draft almost every NAS vendor implemented it. Radius support became a de-facto requirement for a NAS, at least for selling to the ISP market. Eventually, pressure from vendors and users for what became known as a AAA (authentication, authorization, and accounting -- the basic functions of Radius) standard, became strong enough that in December 1995 a Radius working group was established in the IETF. The group's charter was limited to documenting and "cleaning up" the existing Radius draft, with no new features or protocol changes. The initial Radius RFC (2039) was issued in January 1997. The current standard Radius RFC (2865) was issued in June of 2000. (When the IETF updates a standard it issues an RFC with a new number and notes that the old RFC has been superceded.) In addition to the standard RFC, a Radius accounting specification was also documented in an "informational" (not standard) RFC, and in June 2000 a Radius Extensions Informational RFC was also written to document additional features beyond what is in the official standard RFC. Since 1997 Radius has been an accepted IETF standard. The IETF Radius
Page 22 of 45
RFC, along with the Radius accounting and Radius extensions RFCs, have become the official standards for Radius implementers." [RADIUSrising.pdf]
Operation
Like Tacacs, Radius is also a client-server system in which the router sends authentication requests to a Radius server. Radius is now defined in RFC 2865 (which superceded RFC 2138). One thing to note about Radius is that the early deployment of RADIUS was done using UDP port number 1645, but this conflicts with the "datametrics" service, so the officially assigned port number for RADIUS was changed to UDP port 1812. Note: Radius accounting is now defined in RFC 2866 (which superceded RFC 2139). The early deployment of RADIUS Accounting was done using UDP port number 1646, which conflicts with the "sa-msg-port" service. The officially assigned port number for RADIUS Accounting is now 1813. When a RADIUS server authenticates a user, the following events occur: 1. The user is prompted for and enters a username and password. 2. The username and encrypted password are sent over the network to the Radius server. 3. The user receives one of the following responses from the Radius server: ACCEPT - The user is authenticated. ACCEPT-REJECT - The user is not authenticated and is prompted to re-enter the username and password, or access is denied. The Radius server sends this response when the user enters an invalid username/password pairing. CHALLENGE - A challenge is issued by the Radius server. The challenge collects additional data from the user. CHANGE PASSWORD - The Radius server issues a request asking the user to select a new password. An ACCEPT or REJECT - response can contain additional information for services that the user can access, including Telnet, rlogin, or local-area transport (LAT) connections, and PPP, Serial Line Internet Protocol (SLIP), or EXEC services. Radius is commonly used when PPP is used, especially with dial up. RFC 2865 defines a number of attributes that can be sent between the client and the Radius server. These attributes carry specific details about AAA functions. Table 9 provides details from some of the most common attributes. Be aware that many vendors define proprietary attributes, and simply saying something runs RADIUS does not guarantee multi-vendor interoperability. Table 9. Representative RADIUS attributes Attribute type 1 2 Attribute contents User-Name (defines usernames, such as numeric, simple ASCII characters, or a Simple Mail Transfer Protocol [SMTP] address) User-Password (defines the password, which is encrypted using Message Digest 5 [MD5])
Page 23 of 45
3 4 5 6 7 8 9 10 11 12 13 19 26 61
CHAP-Password (used only in access-request packets) NAS-IP-Address (defines the NAS's IP address; used only in access request packets) NAS-Port (this is not the User Datagram Protocol (UDP) port number; it indicates the NAS's physical port number, ranging from 0 to 65,535) Service-Type (Type of service requested or type of service to be provided). Not supported by Cisco IOS. Framed-Protocol (defines required framing; for example, PPP is defined when this attribute is set to 1 and Serial Line Internet Protocol [SLIP] is set to 2) Framed-IP-Address (defines the IP address to be used by the remote user) Framed-IP-Netmask (defines the subnet mask to be used by the remote user) Framed-Routing Filter-ID Framed-MTU Framed-Compression Callback-ID Vendor-Specific. Cisco (vendor-ID 9) uses one defined option: vendor type 1 named cisco-avpair; this attribute transmits Tacacs A/V pairs NAS-Port-Type

The debug commands for Radius are very similar to those for Tacacs. Look at the Tacacs example and you will see the method "tacacs" specified. If you were using Radius, you would see "radius" instead. As you can see, there is no special debug aaa command for just Radius as compared to Tacacs.
SCHO-TermSRV#debug aaa ? accounting Accounting administrative Administrative authentication Authentication authorization Authorization per-user Per-user attributes pod AAA POD processing
Here is an example that is specific to Radius.
router# debug aaa authentication 12:12:45: AAA/AUTHEN (1202654323): Method=Radius 12:12:45: AAA/AUTHEN (1202654323): status = GETPASS 12:13:50: AAA/AUTHEN/CONT (1202654323): continue_login 12:13:50: AAA/AUTHEN (1202654323): status = GETPASS 12:13:54: AAA/AUTHEN (1202654323): status = PASS
The other major debug command for Radius is the debug radius command. Here is some sample output.
router# debug radius 04:34:52: Radius: IPC Send 0.0.0.0:1645, Access-Request, id 0xA, len 57 04:34:52: Attribute 4 6 AC150E5A
Page 24 of 45
04:34:52: Attribute 5 6 0000000A 04:34:52: Attribute 1 7 62696C6C 04:34:52: Attribute 2 18 49C28F6C 04:34:57: Radius: Received from 172.16.1.1:1645, Access-Reject, id 0xA, len 20
Kerberos Brief historical overview

Kerberos is an authentication protocol in the application layer (Layer 7) of the OSI model. Kerberos was developed at the Massachusetts Institute of Technology (MIT) and uses the Data Encryption Standard (DES) cryptographic algorithm for encryption and authentication. Kerberos uses a trusted third party server, called the Key Distribution Center (KDC) for authentication. Note that Kerberos supports Telnet, rlogin, rsh, and rcp.
Operation
Here is an example that explains the process. In this example, a remote user initiates a Telnet session.
Figure 4. Kerberos flow Unlike Tacacs and Radius, Kerberos is used only for authentication, not authorization and accounting. Kerberos is quite different from Tacacs and Radius. It is not just a simple client-server model. The way that Kerberos works is to have a trusted Kerberos server, known as the Key Distribution Center (KDC), issue tickets (also known as credentials) to remote users. The term "user" also has a different definition from Tacacs or Radius. With Kerberos, a "user" can be either a person or a device such as a router. The tickets have a limited life span and are stored in a user's credential cache for use in place of the standard username/password combination. With Kerberos, terminology is very important. A Kerberos "ticket" or "credential" is a general term that refers to authentication tickets, such as ticket-granting
Page 25 of 45
tickets (TGTs) and service credentials. Kerberos credentials verify the identity of a user or service. If a network service decides to trust the Kerberos server that issued a ticket, it can be used in place of retyping a username and password. By default, credentials have a life span of eight hours. A TGT is a specific credential that the KDC issues to authenticated users. When users receive a TGT, they can authenticate to network services within the Kerberos realm represented by the KDC. A "service credential" is another type of credential for a network service that is issued by the KDC. It includes the user's TGT, and is encrypted with the password shared by the network service and the KDC. Another important term for Kerberos is the "SRVTAB". An "SRVTAB" is a password that a network service shares with the KDC. A network service authenticates an encrypted service credential using the SRVTAB (also known as a KEYTAB) to decrypt it. Kerberos uses an idea called "single logon." The whole idea behind the "single logon" concept is that a user has to authenticate only once. After that successful logon, the user will be issued a credential that allows the user to logon with secure authentication wherever that credential is accepted. Later improvements to Kerberos include Timestamps to aid in the prevention of replay attacks. This is the reason that NTP is a requirement for Kerberos on Cisco IOS devices. Another important term used when discussing Kerberos is the concept of a Kerberos Realm. A Kerberos Realm is a domain that consists of all the users, hosts, and network services that are registered with a KDC. The Kerberos Realm must always be in uppercase characters. The Kerberos realm is also used to map a DNS domain to a Kerberos realm. TCP fragmentation must be enabled on the KDC. Here is a summary of Kerberos features: Table 10. Kerberos features Feature Packet Delivery Packet Description Telnet Support Description Kerberos uses a number of ports, including: TCP/UDP ports 88, 543, 749, and TCP ports754, 2105, and 4444. Supports username/password encryption. Telnet sessions can be encrypted (this is known as Kerberized Telnet)
Although Kerberos is not as common as Radius and Tacacs, Kerberos is still in use. For example, Microsoft 2000 uses Kerberos for internal authentication in Active Directory. For more information about Kerberos, visit MIT's Kerberos site: http://itinfo.mit.edu/product?name=kerberos

Here is an example of what debug aaa authentication looks like with Kerberos.
Router# debug aaa authentication AAA/AUTHEN/START (214431325): Method=KRB5 AAA/AUTHEN (214431325): status = GETUSER AAA/AUTHEN/CONT (214431325): continue_login AAA/AUTHEN (214431325): status = GETUSER AAA/AUTHEN (214431325): Method=KRB5 AAA/AUTHEN (214431325): status = GETPASS AAA/AUTHEN/CONT (214431325): continue_login AAA/AUTHEN (214431325): status = GETPASS AAA/AUTHEN (214431325): Method=KRB5 AAA/AUTHEN (214431325): password incorrect AAA/AUTHEN (214431325): status = FAIL
Here is an example of debug kerberos in which the login attempt is successful. You can also see the request sent to the KDC and the response from the KDC.
Page 26 of 45
Router# debug kerberos Kerberos: Kerberos: Kerberos: Kerberos: Requesting TGT with expiration date of 820911631 Sent TGT request to KDC Received TGT reply from KDC Received valid credential with endtime of 820911631
Configuring the CiscoSecure ACS Server

You can download and install a trial copy of CiscoSecure ACS for Windows NT/2000 or UNIX by visiting the Cisco Secure Software center on CCO. CiscoSecure ACS has a built-in Radius and Tacacs server with a local user database. You also need a Cisco router with IOS 12.X with one working Ethernet port.
Windows
Here is a sample configuration that shows the basics of CiscoSecure ACS for Windows. Naturally, you can get a lot more complicated than this example, so you will have to experiment.
Figure 5. Cisco Secure ACS for Windows Click on the User Setup icon on the left. Type in the user to add and then click Add/Edit.
Page 27 of 45
Figure 6. User Setup in ACS Fill in the Supplementary User Info fields.
Page 28 of 45
Figure 7. Supplementary User in ACS Select CiscoSecure Database for authentication and enter a password. Notice that some of the other authentication methods include CiscoSecure Database, Windows NT/2000, and RSA SecurID Token Server.
Page 29 of 45
Figure 8. CiscoSecure Database Select the appropriate user group.
Page 30 of 45
Figure 9. ACS User Group Click the Submit button to create the user.
Page 31 of 45
Figure 10. Submitting the ACS User
Adding a Network Device as AAA Client

Click on the Network Configuration icon on the left.
Page 32 of 45
Figure 11. Adding AAA Clients Under AAA Clients, click the Add Entry button.
Page 33 of 45
Figure 12. Adding Client Entries Enter the device name, IP address, and key. Then click on the Submit+Restart button for the changes to take effect.
Using Tacacs accounting

Click on the Reports and Activity icon on the left. Then click on Tacacs Administration.
Page 34 of 45
Figure 13. Tacacs Accounting Information Select the Tacacs Administration file with the appropriate date to examine the accounting data.
Unix
Configuration of Cisco Secure ACS for Unix is beyond the scope of this paper. You can find the basics on CCO. Configuration of the Unix Cisco Secure ACS is also very dependent on which Unix version you are running.
Configuring Tacacs
IOS Tacacs Configuration Task List
To configure a router to support Tacacs+, you must perform the following tasks:
Page 35 of 45
1. Use the aaa new-model global configuration command to enable AAA.
Router(config)# aaa new-model

Warning: The aaa new-model command immediately applies local authentication to all lines and interfaces (except console line line con 0). If a Telnet session is opened to the router after enabling this command (or if a connection times out and has to reconnect), the user has to be authenticated using the local database of the router. To avoid being locked out of the router, I recommend that you define a username and password on the access server before starting the AAA configuration. Do this as follows:
username xxx password yyy

2. Use the tacacs-server host command to specify the IP address of one or more Tacacs servers. The command syntax is as follows:
tacacs-server host hostname [single-connection] [port integer] [timeout integer] [key string]
Here is a practical example:
tacacs-server host 192.168.1.1 tacacs-server host 192.168.1.2

Note: You can define multiple Tacacs servers. You see this a lot with service providers who use it for redundancy in case the first server becomes unavailable. If the first server does not respond within a timeout period (default, 5 seconds), the next server is queried, and so on. A good strategy is to use geographically dispersed Tacacs servers such as Cisco Secure ACS. 3. Use the tacacs-server key command to specify an encryption key for the Tacacs session between the networking device and the Tacacs server. This same key must also be configured on the Tacacs server. The global command is:
tacacs-server key key

Here is an example:
tacacs-server key TheBirdIsSinging

4. Use the aaa authentication global configuration command to define method lists that use Tacacs for authentication. 5. Use line and interface commands to apply the defined method lists to various interfaces. Here is an example:
interface serial 0 ppp authentication default

6. To enable authorization, use the aaa authorization global command to configure authorization method lists. Unlike authentication, which can be configured per line or per interface, authorization is configured globally for the entire NAS. 7. To enable accounting for Tacacs connections, use the aaa accounting command to configure
Page 36 of 45
accounting method lists. Note: You can define multiple Tacacs servers by defining the servers with the IOS command tacacsserver server_ip_address. This is often used for redundancy in case the first server becomes unavailable. If the first server does not respond within a timeout period (default 5 seconds), the next server is queried, and so forth. For example, to define three servers use the IOS configuration:
! New York Tacacs Server tacacs-server host 1.1.1.1 ! London Tacacs Server tacacs-server host 2.2.2.2 ! Tokyo Tacacs Server tacacs-server host 3.3.3.3 tacacs-server key TheBirdIsSinging
Note: One thing to look out for when configuring Tacacs is to make sure to define the Tacacs servers first. Do this because, if you make a mistake configuring the method lists and do not allow local fallback, you can lock yourself out of the router if the Tacacs server is not defined. This will then require a password recovery procedure to fix. Here is the safe way to configure Tacacs on IOS devices and not lock yourself out. 1. Verify that the router has a route to the Tacacs server(s). 2. Verify that the router is able to ping the Tacacs server(s). Verify that TCP port 49 is open all the way from the router to the Tacacs server(s). 3. Verify that the IP address of the router is configured as an AAA client in the CiscoSecure ACS server, with the correct key. 4. Telnet to the CiscoSecure ACS server on port 49. Remember that you may need extra controlshift-6 characters if you are running through multiple forward or reverse telnet sessions. Do not proceed unless you can make a connection. Hit a couple of carriage returns to close the connection.
router> 172.16.1.1 49 Trying 172.16.1.1, 49 ... Open

5. Backup the current router configuration to a TFTP server. 6. Open 2 simultaneous sessions to the router: 1 via console and 1 via telnet. If you run into any issues, back out the changes via the console session. 7. Enter the following commands on the console session in the same order. Keep the Telnet session open. In this example, the Tacacs server is 172.16.1.1.
tacacs-server host 172.16.1.1 tacacs-server key key aaa new-model aaa authentication login default group tacacs+ local aaa accounting exec default stop-only group tacacs+ aaa accounting commands 15 default stop-only group tacacs+ ! ! For termservers, disable authentication for reverse telnet. ! aaa authentication login 1 none
Page 37 of 45
line 33 64 login authentication 1 ! ! Specify source interface if required. ! ip tacacs source-interface int
8. Log out of the Telnet session. 9. Telnet back in. The router should now prompt for a username. Test Tacacs authentication by logging back in with a valid Tacacs account.
CatOS
Here is the safe way to configure Tacacs on CatOS switches. 1. Verify that the switch has a route to the Tacacs server. 2. Verify that the switch is able to ping the CiscoSecure ACS server. Verify that TCP port 49 is open between the switch and the Tacacs server. 3. Verify that the IP address of the switch is configured as an AAA client in the CiscoSecure ACS server, with the correct key. 4. Telnet to the CiscoSecure ACS server on port 49. Do not proceed unless you can make a connection.
switch (enable) telnet 172.16.1.1 49 Trying 172.16.1.1... Connected to 172.16.1.1. Escape character is '^]'.
5. Backup the current config to a TFTP server. 6. Open 2 simultaneous sessions to the switch: 1 via console and 1 via telnet from the loghost. If you run into any issues, back out the changes via the console session. 7. Enter the following commands on the console session in the same order. Keep the Telnet session open.
set set set set set
tacacs server 172.16.1.1 tacacs key key authentication login tacacs enable console primary authentication login tacacs enable telnet primary accounting commands enable all stop-only tacacs+
8. Log out of the Telnet session. 9. Telnet back in. The switch should now prompt for a username. Test Tacacs authentication by logging back in with a valid Tacacs account.
PIX OS
This section describes how to implement authentication and authorization for traffic through the PIX
Page 38 of 45
Firewall, using a server. These commands are in addition to the required basic firewall configuration. Note that the PIX supports only authentication and authorization. It does not support accounting. In the example below, the aaa-server command specifies the IP address of the Tacacs authentication server. The aaa authentication command statement specifies that users on network 192.168.10.0 starting FTP, HTTP, and Web connections from the inside interface be prompted for their usernames and passwords before being permitted access to the servers on other interfaces. The aaa authorization command statement lets the users on 192.168.10.0 access FTP, HTTP, or Telnet, and any TCP connections to anywhere, as authorized by the AAA server. Even though it appears that the aaa commands let the PIX Firewall set security policy, the authentication server actually does the work, deciding which users are authenticated and what services they can access when authentication is permitted.
Example - Authentication and Authorization Commands

aaa-server Tacacs+ protocol tacacs aaa-server Tacacs+ (inside) host 10.1.1.12 TheBirdIsSinging aaa authentication include ftp inside 192.168.10.0 255.255.255.0 0 0 Tacacs+ aaa authorization include ftp inside 192.168.10.0 255.255.255.0 0 0 aaa authentication include http inside 192.168.10.0 255.255.255.0 0 0 Tacacs+ aaa authorization include http inside 192.168.10.0 255.255.255.0 0 0 aaa authentication include telnet inside 192.168.10.0 255.255.255.0 0 0 Tacacs+ aaa authorization include telnet inside 192.168.10.0 255.255.255.0 0 0
This is the safe way to configure Tacacs on PIX firewalls. 1. Verify that the PIX has a route to the Tacacs server. 2. Verify that the PIX is able to ping the Tacacs server. 3. Verify that the IP address of the PIX is configured as an AAA client in the CiscoSecure ACS server, with the correct key. 4. Backup the current config to a TFTP server. 5. When configuring an HA pair of PIXs, console to both. Test authentication on the secondary PIX and keep the console session to the primary open. If you run into any issues, back out the changes via the session on the primary PIX. 6. When configuring a single PIX, temporarily enable Telnet or SSH. Open 2 simultaneous connections: 1 via console and 1 via Telnet or SSH. If you run into any issues, back out the changes via the console session. 7. Enter the following commands on the console session in the same order. Keep the Telnet session open.
aaa-server ciscosecure protocol tacacs+ aaa-server ciscosecure (interface) host 172.16.1.1 key timeout 10 aaa authentication serial console ciscosecure aaa authentication telnet console ciscosecure
8. Log out of the secondary PIX or the Telnet/SSH session.
Page 39 of 45
9. The PIX should now prompt for a username. Test Tacacs authentication by logging back in with a valid Tacacs account. 10. Disable Telnet or SSH if enabled in step 6.
VPN Concentrator (3005, 3015, 3030, etc.)

Because the VPN concentrator primarily uses a GUI, I don't usually configure it for Tacacs. You can configure the VPN concentrator to use Tacacs to authenticate management accounts. However, there are several problems with this. One problem is that there is no way to track commands entered via the GUI, i.e., accounting. The second problem is that, unlike with IOS, there is no way to configure local authentication in the event that the Tacacs server is unreachable. I found that if the Tacacs server is unreachable, you cannot log in to the VPN concentrator until the Tacacs server is once again reachable.
Configuring Radius
There are many Radius servers available, both commercial and freeware. Radius is also available for most platforms including Microsoft Windows 2000 servers and various flavors of UNIX such as Solaris.
IOS Radius Configuration Task List

Here are the steps necessary to configure Radius on IOS routers: 1. Enable AAA with the aaa new-model global configuration command. AAA must be configured if you plan to use Radius. Warning: The aaa new-model command immediately applies local authentication to all lines and interfaces (except console line line con 0). If a Telnet session is opened to the router after enabling this command (or if a connection times out and has to reconnect), the user has to be authenticated using the local database of the router. To avoid being locked out of the router, define a username and password on the access server before starting the AAA configuration. Do this as follows:
username xxx password yyy

2. Use the aaa authentication global configuration command to define the method lists for Radius authentication. 3. Use line and interface commands to enable the defined method lists to be used. 4. Define the Radius server and secret key:
radius-server ip_address radius-server key secret_key

There are two optional Radius commands: You can use the aaa authorization global command to authorize specific user functions.
Page 40 of 45
You can use the aaa accounting command to enable Radius accounting. Examples are the best way to show the enormous IOS command set that is available for configuring Radius support with AAA. Here is an example config:
aaa new-model aaa authentication login authRadius group radius local aaa authentication ppp R-user if-needed group radius aaa authorization exec default group radius aaa authorization network default group radius radius-server 192.168.1.1 radius-server key TheBirdIsSinging
The command lines in this Radius authentication and authorization configuration are explained below. 1. aaa new-model enables AAA. 2. The aaa authentication login authRadius group radius local command tells the router to use Radius for authentication at the login prompt with a fallback to the local user database. In this example, authRadius is the name of the method list. If the Radius server returns the REJECT response, the user is denied access and the router will not check its local database. 3. In this example, R-user is the name of the method list defining Radius as the if-needed authentication method in the next line of the configuration: aaa authentication ppp R-user if-needed group radius. This command configures the router to use Radius authentication for lines using PPP with either PAP or CHAP, if the user is not already authenticated. If the user has already been authenticated using the EXEC facility, then Radius authentication will not be performed again. 4. The aaa authorization exec default group radius command sets the Radius information used for EXEC authorization, autocommands, and access lists. 5. The aaa authorization network default group radius command sets Radius for network authorization, address assignment, and access lists. 6. The radius-server 192.168.1.1 command defines the NAS. 7. The radius-server key TheBirdIsSinging command defines the shared secret text string that will be used between the router and the Radius server. Each method list defines the authentication methods used, in sequence, to authenticate a user. Method lists are used to designate one or more security protocols to be used for authentication, including alternatives for authentication in case the initial method fails. This is most commonly used to allow for local authentication in case the Radius server is either unreachable or down. This process continues until there is successful communication with a listed authentication method or the authentication method list is exhausted, in which case authentication fails.
CatOS
CatOS commands for configuring AAA are highly dependent on the particular version the switch is running. Assume here that we are using CatOS 7.5.1. To configure basic Radius on CatOS switches, proceed as follows: 1. Make sure there is a back door into the switch in case something goes wrong by issuing the set
Page 41 of 45
authentication login local enable command.

2. Enable Radius authentication by issuing the set authentication login radius enable command. 3. Define the Tacacs server and set the port to use by issuing the set radius server ip_address auth-port 1812 acct-port 1813 primary command. 4. Define the server key by issuing the set radius key your_key command. At this point, the particular method used to configure authorization is dependent on the particular Radius server being used. There are two common procedures: 1. Tell the switch to send enable requests to the server if the Radius server supports the $enab15$ username by issuing the command set authentication enable radius enable. 2. If the server does not support the $enab15$ username, then you have to set the Service-Type (Radius attribute 6) to Administrative (that is, a value of 6) in the Radius server to drop the user into enable mode on the Radius server. If the service-type is set for anything other than 6administrative the user will be dropped at the enable prompt. Finally, to configure accounting on the CatOS switches, you need to do the following: 1. To enable accounting for reloads of the switch, issue the set accounting system enable start-stop radius command. 2. To enable accounting for users arriving at the user level or enable level prompts, issue the set accounting exec enable start-stop radius command. 3. To enable accounting for users Telneting out of the switch, issue the set accounting connect enable start-stop radius command. 4. You may also want to send a message to the server to update records at a specific interval such as one minute by issuing the set accounting update periodic 1 command.
PIX OS Configuring Radius Authorization

Configuring Radius authorization on a PIX Firewall is considerably different from configuring Radius authorization on a router running IOS. To configure Radius authorization, the first step is to configure access lists on the PIX Firewall for each user group. For example, there could be one list for administrators and a separate access list for regular users. Next, configure the Radius server such as CiscoSecure by listing the access list in the group profile. After the Radius server successfully authenticates a user on the PIX Firewall, it can then use Radius attribute 11 (Filter-Id) to identify an access list for a given user group in the Radius authentication response message. Note: Although access lists can be used with both Radius and Tacacs, only FTP, HTTP, or Telnet can be authorized with Tacacs. Here is an example: Suppose that you wanted to allow regular users to access only two specific servers and deny everything
Page 42 of 45
else:
access-list user permit ip any server1 255.255.255.255 access-list user permit ip any server2 255.255.255.255 access-list user deny ip any any
In this example, the CiscoSecure configuration would need the vendor-specific attribute string set to acl=user to identify the correct access-list name. The PIX Firewall will receive this attribute from CiscoSecure and extract the string and put it in a user's uauth entry. What happens is that when a user tries to open a connection through the PIX, the PIX checks the access list in the user's uauth entry, and permits or denies the connection based on the access-list match. When a connection is denied, PIX Firewall generates a corresponding Syslog message. As with all access lists on the PIX and IOS, there is an implicit deny rule. To enable Radius authorization, perform the following steps: 1. Enable Radius authentication with the aaa authentication command. 2. Define the desired access-list statements to list the services that hosts are authorized to use with Radius in the PIX Firewall. 3. Configure the Radius server with the vendor-specific acl=acl_ID identifier to specify the access-list ID. Here is a practical example:
PIX525(config)# aaa-server RADIUS protocol radius PIX525(config)# aaa-server AuthOutbound protocol radius PIX525(config)# aaa-server AuthOutbound (inside) host 192.168.1.1 TheBirdIsSinging timeout 10 PIX525(config)# aaa authentication telnet console RADIUS PIX525(config)# aaa authentication enable console RADIUS
Configuring Kerberos
IOS
To configure Kerberos support on a Cisco router, you need to complete the following tasks: 1. Define the realm for the router. Here is the syntax:
kerberos local-realm kerberos_realm

2. Define which KDC the router should use in a given Kerberos realm and, if desired, the port number that the KDC is monitoring. (The default port number is 88.)
kerberos server kerberos_realm {hostname | ip_address} [port_number]

3. Map the host name or DNS domain to the Kerberos realm (optional).
kerberos realm {dns-domain | host} kerberos_realm

Example
Page 43 of 45
kerberos local-realm MIT.EDU kerberos server MIT.EDU 192.168.1.1 kerberos realm.mit.edu MIT.EDU
CatOS
Before you can configure Kerberos on a CatOS switch, you need to configure the Kerberos server. You need to create a database for the KDC and add the switch to the database. Note: Cisco recommends that you enable DNS and you must enable NTP to configure Kerberos. (Notice also that the realm, e.g.. MIT.EDU, must be all capitals.) 1. To configure the Kerberos server, you need to create the database that the KDC will use. Here is an example for a database called mit.edu.
/usr/local/sbin/kdb5_util create -r MIT.EDU -s

2. Next, you need to add the switch to the database:
ank host/[email protected]
3. Now add the username:
ank [email protected]
4. Next, add the administrative principles:
ank user1/[email protected]
5. Create the entry for the switch in the database, using the admin.local ktadd command.
ktadd host/[email protected]
6. Move the keytab file to a place where the switch can reach it. 7. Start the KDC server:
/usr/local/sbin/krb5kdc /usr/local/sbin/kadmind
Now that we have the KDC server running, we can configure Kerberos on the switch. For more information on the Kerberos protocol and server, see http://web.mit.edu/kerberos/www/. To configure Kerberos on the switch, do the following: 1. Specify Kerberos as the authentication method using the set authentication login kerberos enable [all | console | http | telnet] [primary] command. 2. Verify with the show authentication command. Here is an example
switch> (enable) show authentication Login Authentication: Console Session Telnet Session --------------------- ---------------- ----------------
Page 44 of 45
tacacs radius kerberos local
disabled disabled disabled enabled(primary)
disabled disabled enabled(primary) enabled
Enable Authentication:Console Session Telnet Session ---------------------- ----------------- ---------------tacacs disabled disabled radius disabled disabled kerberos disabled enabled(primary) local enabled(primary) enabled
3. Define the Kerberos local realm with the set kerberos local-realm kerberos_realm command. 4. Verify with the show kerberos command. Here is an example:
switch> (enable) set kerberos local-realm MIT.EDU Kerberos local realm for this switch set to MIT.EDU. switch> (enable) show kerberos Kerberos Local Realm:MIT.EDU Kerberos server entries: Realm:MIT.EDU, Server:192.168.1.1, Port:88 Kerberos Domain<->Realm entries: Domain:mit.edu, Realm:MIT.EDU Kerberos Clients NOT Mandatory Kerberos Credentials Forwarding Enabled Kerberos Pre Authentication Method set to None Kerberos config key: Kerberos SRVTAB Entries Srvtab Entry 1:host/[email protected] 0 932423923 1 1 8 01;;8>00>50;0=0=0 switch> (enable)
5. Next, specify the Kerberos server to use (and optionally the port number) by issuing the set
kerberos server kerberos_realm {hostname | ip_address} [port_number]

command. In order for remote users to authenticate to the switch using Kerberos, you must copy the SRVTAB entry from the KDC to the switch. The switch will use TFTP to do this, so it is not the most secure way. (Note: there are other more secure ways. See the CatOS AAA configuration guide on CCO if you really want another way.) To copy the SRVTAB entry, issue the set kerberos srvtab remote {hostname | ip_address} filename command. Here is an example:
switch> (enable) set kerberos srvtab remote 192.168.1.1 /users/dwolsefer/krb5/cat6509keytab

Kerberos configuration is fairly complex and there are many optional commands. Readers are urged to check out the CatOS AAA configuration guide if you really need to configure Kerberos on a switch. The only place that I know Kerberos is used for sure is on the MIT campus, so I think you will find that Kerberos is fairly rare. You will see Tacacs and Radius deployed much more often.
PIXOS
The PIX Firewall does not support Kerberos. The PIX uses only Tacacs and Radius for AAA.
Page 45 of 45
Conclusion
AAA is an important topic to master, both from a practical real world sense and from a CCIE (especially CCIE Security) perspective. Simply put, I do not know of any service providers that are not using some sort of AAA and many enterprises use it as well. This becomes especially important when you have an environment with a large number of devices. It is just too difficult to manually keep up with users and passwords if you have more than a few devices. Also an accounting audit trail can be very helpful for both troubleshooting and making sure that engineers are following proper change procedures. For the CCIE lab, it is important to remember that anything in IOS is fair game for the Routing and Switching lab. For the Security lab, this is true of other equipment as well. You really need to understand the syntax of method lists and how to troubleshoot and debug AAA because if you get a question about AAA during the lab exam, these should be easy points for you. You don't want to find yourself with no experience or knowledge of AAA as you frantically search the documentation CD. My recommendation is that you practice with both Radius and Tacacs until you are comfortable enough with them that you can configure AAA quickly without any errors. You must be proficient at it and have attention to detail about how you are implementing it so you don't lock yourself out of a router. You don't need to waste time doing a password recovery because you don't know how to configure Tacacs safely.
References
[OrangeBook 1985] 1985 Orange Book - Trusted Computer System Evaluation Criteria, (DOD-5200.28-STD) http://www.dynamoo.com/orange/fulltext.htm [Ada 1995] 1995 Ada Reference Model http://www.adaic.org/standards/95lrm/html/RM-9-4.html [RADIUSrising] http://www.interlinknetworks.com/graphics/news/cs_RADIUSrising.pdf
[IE-AAA-WP1-F02] [2004-02-18-02]

Authentication, Authorization, and Accounting Protocols (AAA)

Uploaded by

Copyright:

Available Formats

Authentication, Authorization, and Accounting Protocols (AAA)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Authentication, Authorization, and Accounting Protocols (AAA)

Uploaded by

Copyright:

Available Formats

Certification Zone - Tutorial