This operations guide describes the operation of the xtacacsd Extended TAC server for Cisco terminal/communication servers.
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 192.100.100.11 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 192.1.3.4 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.
tacacs-server extended tacacs-server host 192.1.1.1 tacacs-server host 192.1.1.15 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 202.100.94.101 interface async 1 ppp use-tacacs [single-line] arap use-tacacs [single-line] async mode interactive !
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>]
GROUP 10 HOST 198.138.178.0 MASK 0.0.0.255 LINE 1,2,5-9 LOGIN PERMIT
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.
This version of xtacacsd supports a wide variety of authentication methods.
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.
On systems using shadow password files, compile with -DSHADOW defined.
On Digital Unix systems using Digital Security (SIA), compile with -DSIA.
By using special keywords in the password file, you can use the external programs provided by SDI or Enigma Logic to authenticate your users.
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).
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.
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.
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.
Original version of tacacs written by Greg Satz (satz@cisco.com), Cisco Systems, 1989.
