TACACS+, Part II

icon TACACS+, Part II

Introduction

Here we are at the end of another lively month. I just took and passed my CCIE (Cisco Certified Internetworking Expert) exam, which was quite an experience.

Two months ago we talked about configuring TACACS+ on a Cisco router or NAS (Network Access Server). That's the TACACS+ client.

This month, we'll talk about the server end of things. We'll look at what I know about a new Cisco product, CiscoSecure It should be announced by the time this article appears.

CiscoSecure is a commercially supported version of the TACACS+ server, initially for the SunOS (4.1.3 or later) platform. Applicable disclaimer: Mentor Technologies had a hand in developing this product. The following article briefly tells you about the product, but then focusses mainly on the technical side of things, since the press releases should adequately cover the rest.

Before we start, I'd like to mention one new feature of TACACS+ on Cisco routers: the Radius protocol should be supported as of IOS version 11.1. That means 'radius' will be another keyword option for how the aaa model does authentication.

CiscoSecure

Maybe the best way to briefly introduce CiscoSecure is to tell you what's in the box (besides documentation, license forms, and the like).

The first thing you get is a carefully designed and optimized TACACS+ server daemon. This is software that codes up the TACACS+ protocol, with an eye towards scaling issues (like up to 500,000 users at up to 30 transactions per second). It has fairly low memory and resource utilization.

The second major component is the GUI software, for administering the user database without that nagging feeling you're programming something.

The big win is that CiscoSecure provides central control of access to your network. By not having to configure users and passwords into multiple devices, memory and support time are conserved.

The product supports user password change and password aging, with configurable warning period. It can also reject easily guessed passwords. There are message catalogs for configuring language-independent messages. And protocol transactions can be encrypted, to defeat snooping.

There is a file containing settings, globally configuring the system. There is also a collection of files, the user database, normally administered via the GUI. The server is notified when changes have been made, and cuts over to the new configuration in a non-disruptive, non-stop manner.

The accounting log can collect information such as username, user network address, attempted service, protocol used, time and date, and packet filter module where the logging information originated. Billing information includes connect time, userid, connection location, amount of data transferred, start time and stop time.

The User Database

This is also known as the AA database. Its syntax is specified in BNF form in an appendix to the documentation.

Normally you don't have to deal with it, that's what the GUI is for. I thought we'd talk about it some, since that will give a better idea of what you can do with CiscoSecure.

The AA database is built of users and groups, with an inheritance model. There is also a notion of default, or what's available to an unknown user (in future versions, this may become 'unknown_user', as it is currently a minor source of possible confusion). You can set things up so all groups belong to a 'root' or other group with standard settings. This can then be selectively overridden for selected groups.

The four basic entities in the database are users, groups, default, and comments. Users can belong to groups. Groups can also belong to groups. Circular membership is not allowed. Users inherit from the group they belong to, if any. Each group also inherits from any group it belongs to, and so on, recursively.

In the AA database syntax, this looks like

default = {
        password = system # /etc/passwd
}
group = staff {
        password = des sef123ghjEz
        ...
}
user = johndoe {
        # johndoe uses the group password
        member = staff
}
user = suedoe {
        member = staff
        # sue has her own password
        password = des adfj123FFlj
}
The GUI provides an interface showing the group membership tree, with the ability to modify what's specified at any level of the tree.

There are also declarations and services (shell or protocol). Declarations are the things you might specify about a user or group:

  • what they're allowed or forbidden to do (for example, telnet),
  • under what circumstances that applies (certain times of day), and
  • any modifiers on what's authorized (perhaps telnet is limited to selected addresses)
Services allow grouping of declarations.

An example should make this a great deal clearer. Perhaps we wish to authorize use of telnet from a command line (NAS exec prompt). We do this with

service = shell {
        cmd = telnet {
                time = Mo, Th 1700 - 0900
                time = Sa, Su 0000 - 2359
        }
        ... # more commands
}
... # more service clauses
Within the telnet command clause, we specify attributes that modify the telnet command, like addresses to deny or permit telnet to. The above example shows times limiting when telnet is permitted: telnet is only allowed outside business hours or on weekends.

Similarly, PPP can be controlled by having a service statement like

service = ppp {
        protocol = ip {
                set addr = 123.123.1.1
                set inacl = 110
                set outacl = 120        
        }
}
...
This specifies that IP protocol is allowed over PPP, with the end-node address being 123.123.1.1, and inbound and outbound access lists 110 and 120, respectively. This could be done on a per-user basis, although it is less work to do it for a group at a time.

There are a wide variety of qualifiers and modifiers or attributes. Qualifiers include expires, time, valid, allow, refuse. Expires and valid govern when information is applicable, time is a time block, as above, and allow / refuse qualify a command based on what NAS address or port the user is on. Attributes include things like inacl and outacl (as above), addr-pool (address pool), and routing (route to a SLIP or PPP user: true and false). The list of attributes goes on at great length, but I won't.

I hope that gives the flavor of the AA database language, as well as some idea of how expressive it is.


Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This email address is being protected from spambots. You need JavaScript enabled to view it. .

2/96
Copyright (C)  1996,  Peter J. Welcher