Router Expert: TACACS+ tricks with scripts, part 1

This tip provides the scripts for a tool that manages tac_plus user accounting.

Read about Michael

Resourcefulness, n: the ability to deal resourcefully with unusual problems
Thoroughness, n: conscientiousness in performing all aspects of a task
Sloth, n: a disinclination to work or exert yourself

Network and system administrators have three common attributes: resourcefulness, thoroughness and sloth. These virtues came to mind when I was reading a post on a TACACS+ mailing list asking for information about tools for managing tac_plus user accounting. There was little in terms of response -- aside from "you should write one" --because there are no such tools. Now, you may be asking why this request brought these attributes to mind. For starters, the author of the note was being resourceful in reaching out to others to find an answer to his problem. Or maybe the author was thinking about creating a tool and the query was an attempt at being thorough, making sure he was going to devote her energies to fixing a problem that currently did not have an answer. Regardless of the author's intent, the nature of the question indicated the administrator clearly had slothful tendencies. I mean, how hard is it to edit a single configuration file?

But then I thought about it. The advantage of using the tac_plus daemon is its functionality and extendibility over commercial implementations. However, that flexibility comes with a price. While the TACACS+ "service" is provided, not much else is. Commercial TACACS+ implementations come with GUI/CLI tools to administer the system and provide reporting capabilities. Tac_plus offers none of those perks, just a solid TACACS+ service. So for those of you find editing files tedious or are just jealous of your administrator friends with their pricey TACACS+ implementations that have great management interfaces, here is a tool for managing tac_plus user accounting.

The tool consists of three scripts:

  • tadduser -- This script creates user profile entries supporting the following authentication methods: S/Key, clear text, local DES and PAM and group membership assignment.
  • tdeluser -- This script removes dependent user accounts, searches a tac_plus configuration file for removal candidates, and handles error checking and status reporting.
  • pwedit -- This script removes user profile data from a tac_plus configuration file (called by the tdeluser script, not usable as a standalone script).

The scripts are written for the Bourne or BASH shell environment and depend on grep, awk and sed for formatting and editing. They should run in most Unix environments (tested on RH 6.x and RH7.x) with little effort. Only the tadduser script requires some local configuration; the tdeluser and pwedit require no locally set variables. The three scripts also need to be located in the same directory, ideally /usr/local/etc/tacadmin. In terms of the tac_plus operational environment requirements, version 4.0.4 or 4.0.3 of the tac_plus daemon with the Linux PAM Patch is required along with a properly formatted tac_plus configuration file. Past tac_plus articles have referenced the Shrubbery version of tac_plus that does not support Linux PAM, so you will need to patch it. The PAM patch, in case you are wondering, provides the ability to use the PAM/shadow password suite that ships with Linux. It adds the "pam login" value to the attribute A/V pair login. Here is a configuration syntax example:

user = emmet {
  login = pam login
  member = admin
}

Without PAM support, the tac_plus server's local user accounting database cannot be utilized by the tac_plus daemon. We will get to why this is bad in a moment. The format of the tac_plus configuration file plays a key role in the scripts' behavior. The tac_plus daemon has no stringent requirements as far as the format and ordering of the configuration file is concerned, other than proper construction i.e., nesting of the A/V pairs. When editing the configuration file by hand, the ordering is not a real concern. When a script edits the tac_plus configuration file, its format becomes quite important. Scripts use pattern and word matching to find data points in the configuration file to determine what is deleted and what can be added. If the configuration is all over the place or uses the same key words and phrases repeatedly, the script can make mistakes and end up deleting or duplicating important data.

To avoid this from happening, error checking and formatting guidelines are needed. Error checking is handled by the script before making any changes. This pertains mainly to username selections; the script will error out values similar or direct to existing values already present. Attempts to use command flags or the incorrect ordering of command flags will also result in errors. All events -- both successes and failures -- are reported to an error log. The default location is /var/log/tac_user.log. In terms of configuration file formatting, the rules can be summed up in three words: global, group, and user. Here is an example /etc/tacacs.conf file that is compatible with this script package:

# tac_plus configuration file
###########################################

# Global Configuration Values

# Shared Key
key = secretkey
# Accounting file location
accounting file = /var/tmp/acctfile
# Default Authentication
default authentication = pam login
# Default Authorization
default authorization = permit

###### Add ACL statements here


###########################################

# Group Profiles

###########################################
#Add Group Profiles Bellow (the default group is required)



group = admin {
     enable = cleartext "suuser"
     service = exec {
               priv-lvl = 15
     }
}

group = default {
     service = exec {
               priv-lvl = 1
}

############# Enable Users

user = $enab15$ {
     login = cleartext "gl0bal"
}

###########################################

# Users Profiles

###########################################
#The script adds user profiles Below

# Configuration output from: tadduser –pam -g
user = bobbie {
 login = pam login
 #
 member = admin
# created on Apr-14
 }

# Configuration output from: tadduser –d -p
user = sam {
 login = des vy.HupOrQVN..
 #
 member = default
# created on Apr-14
 }

  # Configuration output from: tadduser –d -g
user = bobh {
 expires = "Apr 15 2003"
 login = des 1TD2Xw581yAvw
 member = admin
# created on Apr-14
 }

# Configuration output from: tadduser –s -g
user = ham {
 login = skey
 #
 member = admin
# created on Apr-14
 }

# Configuration output from: tadduser –c
user = pod {
 expires = "Mar 15 2003"
 login = cleartext apassw22
 member = default
# created on Mar-14
 }

The tac_plus configuration file starts with the global configuration variables such as the security key and the default attributes. Shrubbery tac_plus users should also configure their ACLs in this section. Next come the group profiles. In a previous article, I advocated for the group attribute configuration approach. The tadduser tool reflects this belief. Arguably, the authentication method is a key element of a user profile. However, attributes such as a user's privilege level, their command access, etc., are of equal importance when maintaining a security access policy. The tadduser tool is built from a perspective of scalability for large user account volumes where attributes are assigned using group membership, rather than custom user definitions. This allows for a great deal of flexibility and minimizes errors and troubleshooting efforts, since the group definitions need to be configured manually. Technically, there is no limit to the number of groups that can be created, and if need be groups can belong to other groups. The script does require at least one group definition, the default group. The default group's purpose is to function as a placeholder, assigned to a user profile when no group membership is defined. The default group explicitly defines the default EXEC shell access posture, privilege level 1, and basic shell access. As you can see from the example, it's also not a bad idea to configure the enable user definitions within the group section as well. The configuration file ends with the user definition section. The section ordering should be maintained to ensure the script behaves properly, since as a matter of function, it operates appending the user profile definitions to the end of the configuration file.

The tac_plus configuration file example also contains some user profile examples generated with the tadduser tool. A user profile is made up of six lines (including brackets and a creation stamp, not read by the tac_plus daemon). However, not all profiles require six configuration stanzas, so #s are inserted as placeholders when needed to maintain format consistency. The six-line user profile format is needed so that a generic editor can be used to delete profiles. The creation of a user profile requires a username and password method definition. A user's password (when appropriate) and group assignment can be optionally defined using control flags. Here is command syntax for all of the tadduser user profile options (in cases where no password or group definition is defined). The default values set in the script's configuration parameters are used:

S/key Mode:
Create default user -s
Create user w/group -s -g

Clear Text Mode:
Create user default pw w/1d password life -c
Create user w/password -c -p {pass}
Create user w/group -c -g
Create user w/password and group -c {pass} -g

Local DES Mode:
Create basic user -d
Create user w/password -d -p {pass}
Create user default pw w/1d password life w/group -d -g
Create user default pw w/no pw expire w/group -d -gn
Create user w/password and w/group -d {pass} -g

PAM Mode:
Create user default pw w/no pw expire -pam
Create user w/password -pam -p {pass}
Create user w/group -pam -g

Removing a user is quite straightforward, but the username and password method is required (the pwedit script is called by the tdeluser tool and is not directly executable). Here is the command syntax:

S/key Mode:
Delete user -s

Cleartext Mode:
Delete user -c

Local DES Mode
Delete user -d

PAM Mode
Delete user -pam

The clear text and local DES methods are independent of the tac_plus server's local user authentication. These two methods store the user's password credentials in the configuration file. This method has some security drawbacks, mainly because the user cannot administer his own password -- an administrator must set it in the configuration file. When using these methods, the user must provide the administrator a password selection through some secure means, or a password generator such as Linuxbuilt's password generator should be used. As an added level of protection, the script will allow a default password to be used, but will set a one-calendar-day expiration. This can be overridden when using the local DES password method using the –gn operator along with an explicit group definition. The clear text method does not have this option; since it is the most insecure method it is typically used for providing limited access vendor accounts, which are often left in place long after they are needed. If you need to support a clear text password for more then one day, you are free to modify the tadduser script.

The S/Key and PAM methods are dependent on the tac_plus server's local authentication services. The S/Key one-time-password method assumes that the user already has an S/Key account (and that your tac_plus daemon has S/Key support). Of the available methods, S/Key provides the greatest degree of security; for accounts with configuration privileges, S/Key is the recommended method. The PAM method uses the Linux shadow password mechanism that comes default with most Linux distributions. Earlier articles in this series have suggested using the tac_plus parameter A/V pair login = file as an option to provide a method to allow users to independently change their passwords using the tac_plus server's local authentication mechanism. This approach requires additional PAM modules and can only be used if you have implemented DES password support using the old crypt algorithm or are generating DES passwords with the generate_password tool provided with the tac_plus distribution (which, unless you create a custom tool, eliminates the ability for users to independently change their passwords).

Adding the PAM support patch makes it quite easy to support a method for configuring the TACACS+ server to allow users to change their password without a command shell. You can simply add /usr/bin/passwd as a permitted user shell in the /etc/shells file. Then set /usr/bin/passwd as the user shell using the –s option flag when creating a user with the /usr/sbin/adduser tool. This method is the default action with the tadduser tool when the PAM option is selected as the users password method. With this method in place, users can connect to the tac_plus server via telnet or SSH and change their password. Here is dialog interface example:

[auser@foo /root]# ssh -l auser tacacs
auser@tacacs password:
Changing password for auser
(current) UNIX password: ********
New UNIX password: *********
Retype new UNIX password: ********
passwd: all authentication tokens updated successfully
Connection to tacacs closed.
[auser@foo /root]#

Well, that's about it for "TACACS+ tricks with scripts, part 1." I hope you find this tool valuable, either as it is or as a basis for creating your own tool. The scripts contain documentation along with the functions. It is advisable to look them over before using them. Next month we will look at some simple utility scripts for controlling the tac_plus daemon and generating some simple reports from the TACACS+ accounting data. So stay tuned.

Was this article helpful to you? Do you have suggestions for topics you'd like to see covered? Please e-mail us and let us know!

This was first published in April 2003

Dig deeper on Network Administration

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close