xtacacsd v4.1 Operations Guide

Vikas Aggarwal
Document Release 4.1a

This operations guide describes the operation of the xtacacsd Extended TAC server for Cisco terminal/communication servers.

Table of Contents


xtacacsd [ -s ] [ -c configfile ]
xtacacsd [ -dqQs ] [ -c configfile ]

Most of the options are listed in the configuration file.

-d debug mode (will not fork if running with -s option).
-s standalone mode (not running within inetd). Use only for testing.
-q quiet mode- DENY type responses never sent back
-Q quiet mode2- quiet only if user not found (NOUSER)
-c configuration file Configuration file for xtacacsd. Typically /etc/xtacacsd-conf. Most options are listed in this file.


xtacacsd is an extended TACACS server (for Cisco network devices) which authenticates users logging onto a terminal server (or any host which cares to query the server). It uses the standard password file (/etc/passwd ) by default, or an alternate list of password files.

This program can be used to authenticate users when they try to access a terminal server ( cisco terminal servers support this option). The server can log information about all queries coming to the server using syslog. It is meant to be invoked by inetd but can be run from a terminal in standalone mode if desired. In this mode, it writes all errors to the controlling terminal. It the '-d' option is specified on the command line (along with -s), it will not fork so all debug messages and errors will be printed on the stderr.

The server expects a username and password to be supplied in the query packet recieved from the terminal servers. This username and password are authenticated by searching in the password file(s). (The default is /etc/passwd but upto five alternate filenames can be specified). If it cannot find a match in any of the password files, it sends an authentication failure reply to the query (unless the quiet option is specified in which case no negative response will be sent).

The server always returns an authentication failure for any queries that have a uid of 0 ( root uid ) or for any users that do not have a password (null password field) in the password files. It also verifies that the account is current and not expired if the last password field (pw_shell) supports this feature (or if the password file has an expiry field on System V based machines). Finally, permissions are checked for the request by matching the username, group-id and gecos field of the user in the tacacs request (the groups listed in the /etc/groups file are checked as well). The permissions are specified in the configuration file as described in the CONFIG FILE section below.


Extended TACACS (xtacacs) is a client-server authentication paradigm described fully in RFC-1492, for authentication of users dialing into terminal servers (Cisco). Users dialing into the Cisco enter their username and password on the terminal server. The cisco then sends these to the Unix xtacacsd daemon which sends back an OK or a DENY. Besides confirming passwords for just logging in, xtacacsd can also permit or deny requests for going into PPP mode or apply access control lists depending on the username or group.


These security mechanisms work by the local and remote hosts encrypting the same data using the user's password (or "secret"), and then comparing the encrypted values of the challenge. This avoids having to transmit the secret in clear text during the entire handshake. However, note that the secret has to be stored in clear-text on the Unix host, presenting a possible security risk.

ARAP requests send an extended tacacs packet with the user name immediately following the xtacacstype structure and it's length is specified in the namelen field. Following that are two ARAP challenges. One from the remote client and one from the commserver. Both are 8 bytes long and the pwlen value must be 16 bytes. Both challenge values are DES encrypted using the users secret and the resulting two values are sent back. Both response values are 8 bytes long. They are appended after the xtacacstype structure (in the respective order that they were recieved in). The version field must be the same as one in the received packet. The namelen must be set to 0 and the pwlen must be set to 16.

CHAP requests come with a user name value with the length specified in the namelen field. In the password field there is a single byte id value followed by a challenge. The id is from the CHAP message that the commserver recieved, or is preparing to send. The challenge value is a stream of bytes that the commserver recieved or is preparing to send. The length of the challenge is pwlen - 1. (The -1 is for the id byte.)

xtacacsd must create a new stream of bytes that looks like: <id><user secret><challenge> and perform an MD5 hash of that stream. The return packet must have the same version number that was received, namelen set to 0, pwlen set to 16 (the size of an MD5 hash) and the xtacacstype structure is immediately followed by the MD5 hash. CHAP requests may arrive when a remote user is trying to authenticate to the commserver, or when the commserver has been asked to authenticate to the remote node. In the latter case, the username in the request will be the name of the commserver.

To compile with the ARAP support, you must get the DES libraries separately. If you are in the United States or Canada, you may get these files from ftp.cisco.com.

This version of xtacacsd assumes the user's password field (in the password file) is the secret (stored in clear text). The password file format is used for CHAP and ARAP secrets simply for convenience. A simple way to separate your arap and chap entries is to make sure that you use different usernames for the regular logins and the chap/arap logins.

The xtacacsd daemon simply creates the ARAP and CHAP responses and sends them back to the cisco- it does not authenticate the connection by comparing the challenges with the response, etc. This is done by the cisco CommServer.

Note that the `secret' has to be stored in cleartext and hence you MUST protect these files from being readable by anyone except root. Since the xtacacsd daemon runs as root, you should set the file permissions on the alternate password files to be 0600.

Alternatively, one can use the arap use-tacacs single-line or the chap use-tacacs single-line cisco configuration commands upon which the user logging in specifies the username as <username>*<password>, and the password is always arap (or chap) This sneaks the username/password pair through in clear text. The terminal server notes the * character in the username, and splits that into a username/password pair, and then issues a XLOGIN xtacacs query to the xtacacs server. Note that in this case there will be no difference between a regular LOGIN request and a ARAP or CHAP request (however, you dont have to worry about having the passwords in clear text on your system somewhere).


xtacacs on the cisco Communication servers support two types of configurations- authentication and notification. Authentication requires a response from the tacacs server to indicate whether the user can perform the indicated action. Services that can be authenticated are login, enable, slipaddr and slipon. Notification messages are just information messages for terminal connections, slipoff and logout that are sent by the Cisco communication server.

The `slipaddr' service is essentially a dynamic address selection on the dialup line. Thus, a remote dialup user who always wants to get the IP address can dialin and request to be assigned his `personal' IP address. Authentication of these requests means that the user has to supply a password for the IP address desired, and the tacacs server will check the supplied IP address and password.

To facilitate configuration, it is easier to map the IP address to a hostname (via DNS) and then let the user supply this hostname instead of an IP address. Preferably, this hostname will be the same as the username used for logging in, so only one entry needs to be made in the password file used by the tacacs server for authenticating.

Alternatively, the terminal server can have static `default' IP addresses assigned to the dialup lines and a user can use `slip default' instead of requesting an IP address using the slipaddr query.

When a user issues a `slip default' command, the cisco does not ask for a username and password. Instead, it sends a SLIPON message to the tacacs server with the username (which the user had supplied upon login) in the request. The tacacs server can either permit/deny this request alongwith a SLIP access-list to be applied. Logins can be forced by specifying the `always' keyword in the Cisco configuration.

For SLIP/PPP support where you want the user to be able to ask for a particular IP address, put an entry in your nameserver mapping the username into a hostname, so that the user can do a slip myuser_name on the cisco and use the same password as he did when logging in. This is preferred instead of using the cumbersome slip and you will not need to make a separate entry in your password file.

For CHAP/ARAP support, you can create a separate password file with the CHAP & ARAP secrets in clear text (yes, the secrets are in clear text if you are not using the single-line keyword in the cisco configuration). Make sure that this file is set mode 0600 so that only root can read it.

The current xtacacsd server implementation always returns an OKAY response to a `connect' message, since the same functionality can be achieved using an ACL applied during login.

Cisco Configuration

Configure the cisco using the commands:
tacacs-server extended
tacacs-server host
tacacs-server host
tacacs-server last-resort password
tacacs-server notify connect
tacacs-server notify slip
tacacs-server notify enable
tacacs-server notify logout
! In Cisco IOS v11.0, allow queries to a host using 'user@host'
tacacs-server directed-request
tacacs authenticate enable
tacacs authenticate connect
tacacs-server authenticate slip [ always ] [ access-lists ]
! In v10.3 of Cisco software, set enable levels
enable use-tacacs
enable last-resort password
ppp auth chap
line 1
 login tacacs
 slip address dynamic

interface async 1
  ppp use-tacacs [single-line]
  arap use-tacacs [single-line]
  async mode interactive

xtacacsd Configuration File

This version of xtacacsd supports a configuration file on the command line. Click xtacacsd-conf to see a sample configuration file.

The config file consists of boolean options and also an authentication section. Each line in this section consists of:

<list type> <keyword> HOST <hostname> [MASK <mask>] [LINE <numbers>] <request type> <action> [<args>]
List Types
There are three permission lists: user, group, and gecos. For the user-list, the key is the username, for the grouplist it is the gid, (NOT group-name, and the /etc/group file is also checked) and for the geco-list it is a geco string match (the last portion of the geco string if it has fields separated by commas).

Request type
login During initial login into the communication server.
connect To authenticate connect type requests (unused)
enable To authenticate enable type tacacs requests. Note that if you do not define a ENABLE_USER (see compile time options), then you should use this to control which user can enable. Users permitted to enable will be able to do so with their own username and password if ENABLE_USER is not defined. In cisco releases 10.3 and higher, the user can type enable 12 where 12 is the enable level. Note that an enable N line in the config file does not imply that the user can do a enable N-1 i.e. the requested level must match the configured level exactly.
slipon Authentication requests to permit going into SLIP mode. Note that this is a new feature available in CommServer releases 9.21(5) and higher only.
slipaddr Authentication requests to allocate the desired IP address for going into SLIP mode. all Any and all tacacs requests.

permit Send back a XTACACS_A_ACCEPT response. Stop trying to match any more permission lines.
deny Send back a XTACACS_A_REJECT response. Stop trying to match any more permission lines.
norouting If the request type is SLIPON and has the ROUTING flag set, send back a REJECT response. Stops searching for any more matches.
acl Aend the access-list number specified in the argument field in the tacacs response.
numlogin Check the UTMP file for the number of current login's into the various servers on the network. Set the maximum number of allowed login's to the value in the argument field. If the number of logins exceeds the limit, a REJECT response is sent and no more searches are done. Otherwise no action is performed.
getok Run the external program specified with the username, group-id, hostname and dialin port number as command line arguments. If the external program returns 0, access will be denied, else the rest of the lines will be processed until an explicit permit or deny condition is met. This program is run AFTER the password authentication. It can be used to deny access to certain users at specific times of the day, depending on the dialin terminal server and port, etc.
execpermit Execute the specified program, while granting access at the same time. The program specified in the argument field is executed in the background, with the username, hostname and line number tacked on on the command line. Stops searching for any more matches.
execdeny Execute the specified program, while denying access. Similar to the execpermit option. Can be used to setup dialback for remote users. Stops searching for any more matches.

If the key, hostname & request_type match, the specified action is performed.

All configuration file entries are processed in the order they are read. The first permit or deny match will stop any further searches. Note that ACL entries do not set permit or deny, so put these entries first in the config file. All other entries set permit or deny explicitly on matching the key, and will cause an immediate return without further searches.

Other Options

(blank passwords) Normally, the xtacacsd daemon denies all requests where the password field for the user is blank. However, this option permits blank passwords which would normally be used for allowing anonymous FTP users to log in.
Use this option with care and apply careful restrictions via access lists to prevent undesired breakins.

Logs additional debugging information (to sys_log or on the terminal in standalone mode). Extensive debugging information is obtained by compiling the program with the -DDEBUG option.

With this flag, the xtacacsd daemon will update and maintain a separate WTMP file for each Cisco sending the xtacacs query. It was useful earlier to use the standard Unix 'ac' or 'last' utilities to create accounting reports. The names of the wtmp files created will have the same basename as the WTMP file and have the hostname appended to it.
This option performs case insensitive username matches in the alternate password files. Due to limitations in the system getpwent() calls, the username is converted to all lowercase and then searched in the /etc/passwd file. Hence, if a query is made where the username in the password file is in mixed case, then it will not be possible to extract the entry from the system default password file (however, this is not a limitation in the alternate password files). This option is useful in PPP queries since the cisco terminal servers convert all PPP username queries to uppercase.
Log all INFO level messages via syslogd also. Without this option, only errors are logged. The logging is done at the facility set during compile time (LOG_LOCAL6).
Disables the use of the nameserver to resolve internet addresses into names. This speeds up responses in case the nameserver is heavily loaded or is down. IN any event, it is still advisable to have atleast a cacheing nameserver running on the host with xtacacsd.
So that the server does not send DENY responses to a query. Thus a client can ask the next tacacs server in its list in case of a timeout. Note that if a user has accounts on two systems with tacacs servers, and if the number of logins in being controlled, then the second server might respond even though the maximum number of allowable logins has been reached on the first tacacs server. Furthermore, all login and logout WTMP entries will be made in the xtacacsd server which responded. (The QUIETNOUSER option is more appropriate).
Will not send any response back if the user is not found in the password files. If the user is found and the request is denied for some reason, the server will send back a DENY response.
Search the system's default password file (or NIS, shadow files, etc.) via the getpwent() call for the username. If this option is not specified and alternate password files are listed, then only the alternate password files will be searched for the user. Note that case insensitive username searches cannot be done using this method. However, if you have a 'normal' password file, then you can actually list /etc/passwd as one of the 'alternate' password files and it will do case insensitive searches.
PASSWD <file>
List alternate password files. Upto 5 alternate password files can be specified by repeating these option lines, and the server will search in all the files until it finds a match or else return an error. The alternate password files must be in the /etc/passwd format (use xpasswd to edit the passwords in these files).
UTMP <utmpfile>
Specifies the xtacacsd utmp file to log current online users. You need to set this only if you want to set it to something different from the compile time value). This file is searched for the number of allowed logins. The default file is defined during compile time (typically /var/xtacacs/utmp). The xtacacsd server deletes entries in the utmp file when a user logs out, and also when a cisco server reloads (since the server sends out a xreload xtacacs message to the daemon). However, if the cisco server crashes without sending out a reload message, then the utmp file could get out of sync. In that case, use the tacupd program to delete or add entries in the utmp file.
WTMP <wtmpfile>
Specifies the file where log entries for each user's login and logout are made. You need to set this only if it is different from the compile time value. The provided taclast program can parse and generate reports from this file.
AUTHTOKEN <keyword> <external program>
For authentication using an external program, use these config statements. If the password field in the password file matches the keyword, then the external program is called with the username and password as arguments. If the external program exits with 1, then permit the user, if it exits with 0, then deny (note that these exit values are the inverse of normal shell scripts where 0 is OK).


This version of xtacacsd supports a wide variety of authentication methods.

Alternate Unix password files

Besides being able to use the standard Unix system password file, you can create similar Unix style password files and put them in different directories and xtacacsd will search for the user in them. Upto 5 alternate password files can be listed.

Shadow Passwords

On systems using shadow password files, compile with -DSHADOW defined.


On Digital Unix systems using Digital Security (SIA), compile with -DSIA.

Enigma Logic & Security Dynamics

By using special keywords in the password file, you can use the external programs provided by SDI or Enigma Logic to authenticate your users.

OSF DCE Security

You can link the code with the Transarc (and other) DCE libraries to use the Distributed authentication mechanism of DCE.


Support for extracting user information from the PH CSO name server is available in this version. This software is available from ftp.cso.uiuc.edu. The required field-names and the query type has to be set in the ph.c file during compile time, and the corresponding fields created in the PH database. Support for extracting CHAP and PAP secrets is not yet available.

Note that case insensitive searches cannot be performed in the QI database, so specify IGNORECASE in xtacacsd and use all lowercase usernames in the QI database.

Also, most of the fields such as group, uid, shell should be readable without logging into the server (i.e. these variables should be world readable) since SLIP queries issued by the xtacacsd daemon do not perform a login.

If using the QI server, then the following additional configuration options should be listed in the xtacacsd-config file:

QI_host1 which is the name of the primary CSO server
QI_host2 name of an alternate CSO server
QI_timeout The read timeout in seconds from the CSO servers
QI_type If you have specified a particular TYPE for these entries in the database (e.g. dialup ).
QI_uid The name of the field in the records for extracting the user's UID (used by xtacacs for all logging, etc.). These are numbers in the range 1 - 65535)
QI_gid The name of the field in the records for extracting the user's Group ID (these are supposed to be integers from 0 - 65535). This is used by xtacacsd for access control QI_shell The name of the field for listing the shell- this can be a date string of the format Aug 11 1996 for listing the expiry date of the account.
QI_gecos The name of the field for listing the gecos string (any indentifier string). This is used by xtacacsd for access control (see the description of how elsewhere in this man page).


To facilitate user login record keeping, the server writes formatted syslog messages at the NOTICE level. The format of these messages is:

STAT:Service:Username:UID:GID @ From-Host:line TTY:TransID:Action:Misc
STAT:xlogin:vikas:913:10 @ cs500:line tty5:67:accepted:9

The TransID is the tacacs transaction ID (which is a unique number per tacacs query-reply). It is useful for eliminating duplicate entries from redundant tacacs server logs.

The daemon also writes a one line entry in the WTMP file (which is ASCII and hence can be easily edited). The format of this file is:

Unix-timestamp Comm-Server Terminal-Number Username GroupID

The terminal number is TTYnn for normal logins, and SLInn when the user goes into SLIP or PPP mode. The GroupID is the Unix group of the user from the /etc/passwd file and it is listed in order to facilitate accounting programs in the login records. For logout entries, the first character is a '?' and the reason for logout or other PPP relevant information is listed.

The taclast program included with this software can process these files and give user login times and totals. See the taclast.man manual page for more details.

XTACACS cannot log the bytes or packets transferred by a user since the protocol does not support it. You have to use Radius or TACACS_Plus instead of XTACACS for this feature.


The following are some of the limitations of the xtacacs protocol- these are NOT a deficiency in the xtacacsd Unix software, but are simply not possible using the current tacacs protocol.

  1. Cannot send back a separate IP address than the one that the user asked for.
  2. Cannot use the cisco autocommand configuration to specify a command to execute on the cisco when a user logs into the commServer.
  3. Does NOT log packets or bytes transferred.
  4. Cannot use `autoselect ppp' on the cisco and send queries to tacacs. These are independent features.


Please see the Protocol Limitations and the Sample Configuration sections in this document also.
  1. The xtacacsd daemon writes detailed log messages via syslog(). For detailed log messages, compile with -DDEBUG, increase the debug level and specify logging in the configuration file. Ensure that your syslog.conf is set to log LOCAL6 messages at the debug level.
    local6.debug «TAB» /var/log/tacacs

    Else, comment out the entry in inetd.conf, and run the server in standalone mode with the -s option.

  2. Turn on the debugging on the Cisco commServer using debug tacacs and terminal monitor.

  3. Most systems have a limitation on the number of space separated arguments that you can put in the inetd.conf file. Hence, try to set most of the xtacacsd options in the xtacacsd-conf config file and not on the command line in inetd.conf.

  4. The «groups» specified in the config file should be group numbers and not names (i.e. use `10' instead of `staff', etc.)

  5. For SLIP access via xtacacsd, if the user is specifying a hostname to get an IP address assigned, you must use the IGNORECASE option on the xtacacsd since the Cisco converts the hostname into all uppercase. If you use the `PASSWD DEFAULT' option in the config file, then the program uses the system's getpw() routines to get the username, and the ignorecase option will not work on the system passwd files. However, xtacacsd still tries to convert the query to all lowercase and search the password file again. It is preferable to not specify PASSWD DEFAULT and directly list the passwd file instead. However, if you are using Yellow Pages or shadow passwords, you will have to use `PASSWD DEFAULT' or else create a separate password file.

  6. If no entry is matched in the permissions listed in the config file, the default is ALLOW. However, to prevent any unpredictable situations, you should have an explicit deny or permit wildcard statement as the last line of the configuration.

  7. Enable LEVELS are only available in Cisco software release 10.3 and higher.

  8. There is a Cisco bug in releases 10.3(4) and lower where notification messages are not sent to the alternate xtacacsd server (if two or more servers are listed on the Cisco). In such cases, all wtmp LOGOUT entries are sent to the primary xtacacs server, whereas the LOGIN entries are made on the server where the user is authenticated. If you are using an alternate server, then get the updated Cisco release software to ensure that your wtmp entries are correct on the main and the secondary servers.

  9. Look in the Frequently Asked Questions


This is the program for parsing the WTMP files and give user times.

This program is used to update entries in the UTMP or WTMP files in case the files get out of sync (due to server crashes or reboots).

This program creates DBM databases of password files for faster access by xtacacsd.

A standalone program for editing passwords in alternate password files.

Also, the Unix man pages for inetd(8) inetd.conf(5) services(5) syslog(8) syslog.conf(5) .

Protocol definition in RFC-927, RFC-1492.


This enhanced version of the software and this documentation written and maintained by Vikas Aggarwal (vikas@navya.com) with contributions by many (See complete details in RELEASE).

Original version of tacacs written by Greg Satz (satz@cisco.com), Cisco Systems, 1989.


Freely available from Netplex Technologies Inc. or via FTP from ftp.navya.com under pub/vikas/.

Back to Top


Copyright © 1994-1997 Vikas Aggarwal (vikas@navya.com)