| tac_plus.conf(5) | File Formats Manual | tac_plus.conf(5) |
tac_plus.conf - tacacs+ daemon configuration file
This page is a work in progress.
tac_plus.conf contains configuration information for the tac_plus (tacacs+) daemon.
Each line contains either one of the directives documented below, white-space (blanks or tabs), or a comment.
Syntax enclosed in angle brackets (<>) below, refer to syntax documented elsewhere in this manual page.
accounting syslog;
accounting file = <filename>
The default filename is /var/log/tac_plus.acct.
Since accounting requests occur (and are serviced) asynchronously, it is necessary to lock the accounting file so that two writers do not simultaneously write to it. The daemon uses fcntl(2) to lock the file. Although fcntl(2) locking over NFS is supported on some implementations, it is notoriously unreliable. Even if it is reliable, locking is likely to be extremely inefficient over NFS. The file is best located on a local file system.
The acl is a series of permit or deny statements applied to the source IP address that the client used to connected to the daemon. The first <regex> that matches ends the evaluation and the result is the permit or deny on left. If no entry of the acl matches a given address, the result is an implicit deny.
acl = <name> {
<permission> = <regex>
# deny 66.1.255/24, allow all else in 66.1/16
deny = ^66\.1\.255\.
permit = ^66\.1\.
# implicit deny (ie: anything else)
}
Briefly, if a company had all their loopback interfaces numbered from 66.1/16 (and thus all the tacacs clients are within 66.1/16), this acl might be used to dis-allow a user to login to (or enable on) any router whose loopback interface is in 66.1.255/24.
Note: because acls match against the daemon client's source IP address, the client should be configured to use a stable source such as a loopback interface. For example:
ip tacacs-server source-interface loopback 0
default authentication = file <filename>
Such users will be authentication via the <user> "DEFAULT".
Also see "user = DEFAULT", <default service>, and <default attribute>.
group = <name> {
<user_decl>
}
A group may be recursive; that is a group may be a member of one other group (which may be a member of yet another group, and so on).
host = <IP address> { key = <string> prompt = <string> enable = <password_spec>
}
key specifics the packet encryption <key> for this host.
prompt specifies the username prompt that will be presented to a user.
key = <string>
The double quotes are only necessary if your key contains white-space, key-words, or special characters.
Note: encryption is highly recommended.
logging = <syslog_fac>
user = <name> {
[ <default service> ]
<user_attr>
<svc>
}
Note: seventeen special usernames exist: "DEFAULT", "$enable$", and "$enabN$" (where N is a privilege level number, normally in the range 0-15 on a Cisco). The "$enable$" user is for backward compatibility with previous versions of tacacs that is queried for privilege level 15 in addition to "$enab15$".
Also see the "priv-lvl" AV pair in the "AV Pairs" section below and the <default authentication> directive.
user = <string> {
[ default service = <permission> ]
<user_attr>*
<svc>*
}
Also see the <default service> directive.
[ optional ] <string> = <string>
Optional AV pairs are only sent to the client if it requests them. That is, the client must have included the given AV pair as a mandatory or optional pair in the request.
Some clients react incorrectly and negatively to receiving AV pairs that it did not solicit. Optional AV pairs should be ignored if they are not recognized or not supported in any given context.
Also see the "Configuring Authorization" and "AV Pairs" sections below.
For command authorization, the device should expand all abbreviated commands to their full names and compress adjacent white-space. For example, when the command "config t" is entered it will be expanded to "configure terminal".
cmd = <string> {
<cmd-match>
}
<permission> <regex>
<permission> <regex> ...
<permission>
The <regex> matches arguments of the command <string>. For example, to allow show diag but no other show commands:
cmd = show {
permit diag
deny
}
The end of the <cmd-match> has an implicit <permission> determined by <default service>. So, if the 'deny' had been omitted in the example above, the result of the authorization would be the value of <default service>.
Note: 'cmd-arg' should never appear in a configuration file. It is used internally by the daemon to construct a string which is then matched against the regular expressions which appear in a cmd clause in the configuration file.
Note: when a command has multiple arguments, they may be entered in many different permutations. It can be cumbersome to create regular expressions which will reliably authorize commands under these conditions. Administrators may wish to consider other methods of performing authorization.
default service = <permission>
If omitted, the default is 'deny'.
Note: if used, <default service> must precede all other <svc> directives in a <user> clause.
default attribute = <permission>
Note: if used, <default attribute> must precede all other <svc_attr> directives in a <svc> clause.
DES is the encryption historically used in Unix passwd(5) files. The crypt() function of the system's libcrypt is used to perform the encryption. The libcrypt of modern Unicies tend to support additional encryption algorithms and thus so would tac_plus. See the system's crypt manual page. To utilize another format, use the des keyword followed by the crypt in the format as described in the manpage. Typically it will have a "$1" prefix for MD5, "$2" for blowfish, and so on.
tac_pwd(8) is a utility supplied with tac_plus to assist in performing this encryption.
expires "May 23 2005"
A expiry warning message is sent to the user at login time, starting at 14 days before the expiration date.
If the <user>'s <login> <password_spec> is "file", the "expires" field of the configuration file is not consulted. Instead, the daemon looks at the the "shell" field of the password file entry for a valid expiration date.
If Solaris shadow password files are used for authentication, the "expires" field of the configuration file is not consulted. The expiry field from the shadow password file (if it exists) is used as the expiration date.
Case is not significant.
While the daemon does change directories to / (root) when it starts, it is best to specify files by their FQPN (Fully Qualified Path Name). That is, a path that begins with /. For example, /var/log/file rather than the relative path var/log/file.
192.168.1.1
In general, a <name> must be defined before it can be referenced. For example, before a <user> can be a specified as a member of a <group>, the <group> has to be defined.
file <filename>
cleartext <string>
des <des_string>
PAM
skey
nopassword
skey is an OTP (One Time Password) facility. The daemon must be built with skey (--enable-skey) support.
PAM (Pluggable Authentication Modules framework) is an authentication mechanism (and much more) capable of various types of authentication methods that are chosen by a configuration file. The PAM service name is the name of tac_plus executable, normally "tac_plus". PAM can be used only for login authentication, it is not implemented for enable authorization, and does not support OTP-like challenge system (ie: no additional prompting). The daemon must be built with PAM support, which is included by default if libpam is found.
Note: some cases of <password_spec> do not accept all of these mechanisms.
(permit | deny)
<svc_auth> | <cmd_auth>
The service AV pair is required.
user = bart {
arap = cleartext "arap password"
chap = cleartext "chap password"
enable = <password_spec>
pap = cleartext "inbound pap password"
opap = cleartext "outbound pap password"
pap = des <des_string>
pap = file <filename>
pap = PAM
login = <password_spec>
global = cleartext "outbound pap password"
}
global specifies the authentication method for all services. login applies to normal logins (exec). arap, chap, pap, and opap (outbound PAP) service passwords may be defined separately.
NOTE: a global user password cannot be used for outbound PAP. This is because outbound PAP is implemented by sending the password from the daemon to the client. This is a security issue if the <key> is ever compromised.
enable specifies the enable password. The <password_spec> may only be of type cleartext, des, nopassword or file. If the daemon was compiled with per-user enable support (--enable-uenable), the host enable password will be evaluated iff the user does not have a personal enable password.
login name member - can only be 1 default service = permit
expires "May 23 2005"
arap = cleartext "Fred's arap secret"
chap = cleartext "Fred's chap secret" acl = <string>
enableacl = <string>
In the case of recursion, the first match is returned. host
enable is cleartext, des, nopassword or file only. arap chap expires
May 23 2005 login member password user_attr :=
name = <string> |
login = <password_spec> |
member = <string> |
expires = <string> |
arap = cleartext <string> |
chap = cleartext <string> | #ifdef MSCHAP
ms-chap = cleartext <string> | #endif
pap = cleartext <string> |
pap = des <string> |
pap = file <filename> | #ifdef PAM
pap = PAM | #endif
opap = cleartext <string> |
global = cleartext <string> |
msg = <string>
before authorization = <string> |
after authorization = <string>
Authorizing a single session can result in multiple requests being sent to the daemon. For example, to authorize a dialin ppp user for IP, the following authorization requests would be made from the client:
This request is really done to find the address for dumb PPP (or SLIP) clients who cannot do address negotiation. Instead, they expect you to tell them what address to use before PPP starts up, via a text message.
As you can see from the above, a program which plans to handle authorization must be able to handle a variety of requests and respond appropriately.
Authorization must be configured on both the client and the daemon to operate correctly. By default, the client will allow everything until configured to make authorization requests to the daemon.
With the daemon, the opposite is true; by default, the daemon will deny authorization of anything that isn't explicitly permitted.
Authorization allows the daemon to deny commands and services outright, or to modify commands and services on a per-user basis. Authorization on the daemon is divided into two separate parts: commands and services.
Authorizing:
Command authorization is configured by specifying a list of <regex>s to match command arguments and an action which is a <permission>.
The following permits user Fred to run these commands:
telnet 131.108.13.<any number> and
telnet 128.<any number>.12.3 and
show <anything>
All other commands are denied (by default).
user=fred {
cmd = telnet {
# permit specified telnets
permit 131\.108\.13\.[0-9]+
permit 128\.[0-9]+\.12\.3
}
cmd = show {
# permit show commands
permit .*
}
}
The command and arguments which the user types are matched to the regular expressions specified in the configuration file (in order of appearance). The first successful match performs the associated action (<permission>). If there is no match, the command is denied by default.
Also see the <default authentication>, <default authorization>, <default attribute>, and <default service> directives.
There are some limitations to the authorization that can be done using a configuration file. One solution is to arrange for the daemon to call user-supplied programs to control authorization. These "callouts" permit almost complete control over authorization, allowing you to read all the fields in the authorization packet sent by the client, including all its AV pairs, and to set authorization status and send a new set of AV pairs to the client in response.
Pre and post authorization programs are invoked by handing the command line to the Bourne shell. On most Unix systems, if the shell doesn't find the specified program it returns a status of one, which denies authorization. However, at least one Unix system (BSDI) returns a status code of 2 under these circumstances, which will permit authorization, and probably isn't what you intended.
Note: if your program hangs, the authorization will time out and return an error on the client, and you'll tie up a process slot on the daemon host, eventually running out of resources. There is no special code to detect this in the daemon.
The daemon communicates with pre and post (before and after) authorization programs over a pair of pipes. Programs using the standard i/o library will use full buffering in these circumstances. This should not be a problem, since AV pairs will be read until end of file (EOF) is seen on input, and output will be flushed when they exit.
Fields from the authorization packet can be supplied to the programs as arguments on the command line by using the appropriate dollar-sign variables in the configuration file. These fields are:
user -- user name
name -- client/NAS name
ip -- client/NAS IP
port -- client/NAS port
address -- user address (remote user location)
priv -- privilege level number (0-15)
method -- a digit (1-4)
type -- digit (1-4)
service -- digit (1-7)
status -- (pass, fail, error, unknown)
Unrecognized variables will appear as the string "unknown".
AV pairs from the authorization packet are fed to the program's standard input, one per line. The program is expected to process the AV pairs and write them to its standard output, one per line. What happens then is determined by the exit status of the program.
Note: when AV pairs containing spaces are listed in the configuration file, you need to enclose them in double quotes so that they are parsed correctly. AV pairs which are returned via standard output do not need delimiters and so should not be enclosed in double quotes.
Note: unless special arrangements are made, the daemon will run as root and hence the programs it invokes will also run as root, which is a security weakness. It is strongly recommended that FQPNs are used when specifying programs to execute, and that the daemon is compiled with unprivileged user and group IDs (--with-userid and --with-groupid) so that the daemon is not running as root when calling these programs,
Calling scripts
user = auth1 {
before authorization "/path/pre_authorize $user $port $address"
}
The AV pairs sent from the NAS will be supplied to the program standard input, one pair per line.
If the program returns a status of 0, authorization is unconditionally permitted. No further processing is done on this request and no AV pairs are returned to the client.
If the program returns a status of 1, authorization is unconditionally denied. No further processing is done on this request and no AV pairs are returned to the client.
If the program returns a status of 2, authorization is permitted. The program is expected to modify the AV pairs that it receives on its standard input (or to create entirely new ones) and to write them, one per line, to its standard output. The new AV pairs will be sent to the client with a status of AUTHOR_STATUS_PASS_REPL. No further processing takes place on this request.
If the program returns a status of 3, authorization is denied, but all attributes returned by the program via stdout are returned to the client. Also, whatever the program returns on stderr is placed into the server-msg field and returned to the client.
Any other status value returned from the program will cause an error to be returned to the client.
Note: a status of 2 is not acceptable when doing command authorization.
group = auth1 {
after authorization "/path/post_authorize $user $port $status"
}
The AV pairs resulting from the authorization algorithm that the daemon proposes to return to the NAS, are supplied to the program on standard input, one AV pair per line, so they can be modified if required.
The program is expected to process the AV pairs and write them to its standard output, one per line. What happens then is determined by the exit status of the program:
If the program returns a status of 0, authorization continues as if the program had never been called. Use this if (for example) to just send mail when an authorization occurs, without otherwise affecting normal authorization.
If the program returns a status of 1, authorization is unconditionally denied. No AV pairs are returned to the NAS. No further authorization processing occurs on this request.
If the program returns a status of 2, authorization is permitted and any AV pairs returned from the program on its standard output are sent to the NAS in place of any AV pairs that the daemon may have constructed.
Any other value will cause an error to be returned to the NAS by the daemon.
Current attributes are:
"unknown"
"service"
"start_time"
"port"
"elapsed_time"
"status"
"priv_level"
"cmd"
"protocol"
"cmd-arg"
"bytes_in"
"bytes_out"
"paks_in"
"paks_out"
"address"
"task_id"
"callback-dialstring"
"nocallback-verify"
"callback-line"
"callback-rotary"
Also see the "AV Pairs" section below.
AV (Attribute Value) pairs are text strings exchanged between the client and server of the form "attribute=value". The value may not appear in authorization request packets, indicating that it is null or unspecified. The equal sign ('=') means that this is a mandatory attribute. An asterisk ('*') may appear in place of the equal sign, indicating that it is an optional attribute which either the client or server may not understand or may ignore.
Optional attributes are preceded by the "optional" key-word in the configuration. For example:
priv_lvl = 15
optional allow-shell = true
service=ppp
protocol=ip
addr*131.108.12.44
The following AV pairs specify which service is being authorized. They are typically accompanied by protocol AV pairs and other, additional pairs from the lists below.
aaa authorization exec tacacs+
user = jim {
login = cleartext lab
service = raccess {
port#1 = clientname1/tty2
port#2 = clientname2/tty5
}
}
Requires IOS configuration
aaa authorization reverse-access tacacs+
Incomplete list of Cisco AV pairs. Other vendors may provide additional AV pairs specific to their products.
ARAP, EXEC.
SLIP, PPP/IP.
EXEC.
If cmd is non-null, this is a command authorization request. It contains the name of the command being authorized. For example: cmd=telnet
EXEC.
NOTE: 'cmd-arg' should never appear in a configuration file. It is used internally by the daemon to construct a string which is then matched against the regular expressions which appear in a cmd clause in the configuration file.
EXEC.
EXEC, 11.1 onward.
Note: For IPX, inacl is only valid after 11.2(4)F.
PPP/IP/IPX.
inacl#1="permit ip any any precedence immediate"
inacl#2="deny igrp 0.0.1.2 255.255.0.0 any"
Attributes are sorted numerically before they are applied. For IP, standard OR extended access list syntax may be used, but it is an error to mix the two within a given access-list.
For IPX, only extended access list syntax may be used.
PPP/IP/PPP/IPX, 11.2(4)F.
0 None 1 Stac 2 Stac Draft-9 3 MS-Stac
service=ppp protocol=multilink {
load-threshold=<n>
}
The range of <n> is [1-255].
PPP/multilink - Multilink parameter, 11.3.
service=ppp protocol=multilink {
max-links=<n>
}
The range of <n> is [1-255].
PPP/multilink, 11.3.
EXEC.
EXEC.
PPP/IP, PPP/IPX.
outacl#1="permit ip any any precedence immediate"
outacl#2="deny igrp 0.0.9.10 255.255.0.0 any"
Attributes are sorted numerically before they are applied. For IP, standard OR extended access list syntax may be used, but it is an error to mix the two within a given access-list.
For IPX, only extended access list syntax may be used.
PPP/IP/PPP/IPX, 11.2(4)F.
Note: in 10.3 this attribute was priv_lvl, i.e. it contained an underscore instead of a hyphen.
EXEC.
service=ppp protocol=ip {
route="<dst_addr> <mask> [ <gateway> ]"
}
<dst_address>, <mask>, and <gateway> are <IP address>'s. If the gateway is omitted, the peer's address is assumed.
PPP/IP/SLIP, 11.1 onward.
route#1="3.0.0.0 255.0.0.0 1.2.3.4"
route#2="4.0.0.0 255.0.0.0"
or, for IPX,
route#1="4C000000 ff000000 30.12.3.4"
route#2="5C000000 ff000000 30.12.3.5"
PPP/IP/IPX, 11.2(4)F.
SLIP/PPP/IP.
sap#1="4 CE1-LAB 1234.0000.0000.0001 451 4"
sap#2="5 CE3-LAB 2345.0000.0000.0001 452 5"
The syntax of static saps is the same as that used by the IOS "ipx sap" command. Used with service=ppp protocol=ipx.
PPP/IPX, 11.2(4)F.
Only Cisco extended access list syntax is legal (ipx input-sap-filter <number>). For example:
sap-fltr-in#1="deny 6C01.0000.0000.0001"
sap-fltr-in#2="permit -1"
Attributes are sorted numerically before being applied. Used with service=ppp protocol=ipx.
PPP/IPX, 11.2(4)F.
Only Cisco extended access list syntax is legal (ipx output-sap-filter <number>), e.g
sap-fltr-out#1="deny 6C01.0000.0000.0001"
sap-fltr-out#2="permit -1"
Attributes are sorted numerically before being applied. Used with service=ppp protocol=ipx.
PPP/IPX, 11.2(4)F.
PPP/VPDN, now deprecated, only existed in releases 11.2(1.4) thru 11.2(4.0.2).
ARAP/EXEC, 11.0 onward.
PPP/VPDN, 11.2 onward.
AV pairs reserved for future use (this list may be out-dated):
ppp-vj-slot-compression
link-compression
asyncmap
x25-addresses (PPP/VPDN)
frame-relay (PPP/VPDN)
Note: this AV pair list is NOT complete and not all AV pairs are supported by all vendors. See the vendor's documentation. When a client (or server) receives a mandatory AV pair that it does not understand, the authorization FAILS!
Also see the tac_plus user guide. Some of the callback, appletalk, IPX, VPDN, PPP routing, and address pool related AV pairs found in the user guide have been omitted.
1 User request 2 Lost carrier 3 Lost service 4 Idle timeout 5 Session timeout 6 Admin reset 7 Admin reboot 8 Port error 9 NAS error 10 NAS request 11 NAS reboot 12 Port unneeded 13 Port pre-empted 14 Port suspended 15 Service unavailable 16 Callback 17 User error 18 Host request
1000 Session timed out. This value applies to all session types. 1002 Reason unknown. 1004 Failure to authenticate calling-party number. 1010 No carrier detected. This value applies to modem connections. 1011 Loss of carrier. This value applies to modem connections. 1012 Failure to detect modem result codes. This value applies to modem connections. 1020 User terminates a session. This value applies to EXEC sessions. 1021 Timeout waiting for user input. This value applies to all session types. 1022 Disconnect due to exiting Telnet session. This value applies to EXEC sessions. 1023 Could not switch to SLIP/PPP; the remote end has no IP address. This value applies to EXEC sessions. 1024 Disconnect due to exiting raw TCP. This value applies to EXEC sessions. 1025 Bad passwords. This value applies to EXEC sessions. 1026 Raw TCP disabled. This value applies to EXEC sessions. 1027 Control-C detected. This value applies to EXEC sessions. 1028 EXEC process destroyed. This value applies to EXEC sessions. 1040 PPP LCP negotiation timed out. This value applies to PPP sessions. 1041 PPP LCP negotiation failed. 1042 PPP PAP authentication failed. 1043 PPP CHAP authentication failed. 1044 PPP remote authentication failed. 1045 PPP received a Terminate Request from remote end. 1046 Upper layer requested that the session be closed. This value applies to PPP sessions. 1101 Session failed for security reasons. This value applies to all session types. 1102 Session terminated due to callback. This value applies to all session types. 1120 Call refused because the detected protocol is disabled. This value applies to all session types.
Example Cisco configuration for tacacs+:
aaa new-model
aaa authentication login default tacacs+ local
aaa authentication enable default tacacs+ enable
aaa authorization exec default tacacs+
aaa accounting exec default start-stop tacacs+
!
username root privilege 15 password 0 <root's password>
!
tacacs-server key <your key here>
tacacs-server host <ip_address>
ip tacacs source-interface loopback0
!
enable secret 0 <enable password>
Note that the aaa command syntax varies slightly between some versions of Cisco IOS and CatOS (Catalyst OS) also varies.
Example Juniper configuration for tacacs+:
system {
authentication-order [ password tacplus ];
tacplus-server {
<ip_address> secret <your key here>;
<ip_address> {
secret <your key here>;
timeout 90;
}
}
}
Both of these examples are brief. See the vendor's documentation for a description of what these configuration commands specify and for additional commands and arguments.
WARNING: If not properly configured, it may not be possible to login to the device!
key = "your key here"
accounting file = /var/log/tac.acct
# authentication users not appearing elsewhere via
# the file /etc/passwd
default authentication = file /etc/passwd
acl = dial_only {
# All access routers are in 192.168/16, but except for
# 192.168.0.1 all backbone router are in 198.168.0/24.
# deny access to the backbone routers.
permit = ^192\.168\.0\.1$
deny = ^192\.168\.0\.
permit = ^192\.168\.
}
group = no_backbone {
# permit an exec to start and permit all commands and
# services by default
default service = permit
service = exec {
# When an exec is started, its connection access list
# will be 4. "acl" is quoted because it is a keyword.
# It also has an autocmd
"acl" = 4
autocmd = "telnet duffhost"
}
# group will only be allowed to login on NASes
acl = dial_only
}
group = admin {
# group members who don't have their own login password will be
# looked up in /etc/passwd
login = file /etc/passwd
# group members who have no expiry date set will use this one
expires = "Jan 1 1997"
# deny access to backbone routers
acl = dial_only
}
user = DEFAULT {
service = ppp protocol = ip {
addr-pool=foobar
}
}
user = homer {
default service = permit
member = no_backbone
}
user = fred {
login = des mEX027bHtzTlQ
name = "Fred Flintstone"
member = admin
expires = "May 23 2005"
arap = cleartext "Fred's arap secret"
chap = cleartext "Fred's chap secret"
service = exec {
# When Fred starts an exec, his connection access
# list is 5
"acl" = 5
# We require this autocmd to be done at startup
autocmd = "telnet foo"
}
# All commands except show system are denied for Fred
cmd = show {
# Fred can run the following show command
permit system
deny .*
}
service = ppp protocol = ip {
# Fred can run ip over ppp only if he uses one
# of the following mandatory addresses. If he
# supplies no address, the first one here will
# be mandated
addr=131.108.12.11
addr=131.108.12.12
addr=131.108.12.13
addr=131.108.12.14
# Fred's mandatory input access list number is 101
inacl=101
# We will suggest an output access list of 102, but the NAS may
# choose to ignore or override it
optional outacl=102
}
service = slip {
# Fred can run slip. When he does, he will have to use
# these mandatory access lists
inacl=101
outacl=102
}
}
user = wilma {
# Wilma has no password of her own, but she's a group member so
# she'll use the group password if there is one. Same for her
# password expiry date
member = admin
}
gethostbyaddr(3), passwd(5), regexp(3), tac_plus(8), tac_pwd(8)
Also see the tac_plus User Guide (user_guide) that came with the distribution. The user guide does not cover all the modifications to the original Cisco version nor does this manual page cover everything that is in the user guide (callback configuration, for example).
The tac_plus (tacacs+) developer's kit is a product of Cisco Systems. Made available at no cost and with no warranty of any kind. See the file COPYING and source files that came with the distribution for specifics.
This manual page was adapted from code inspection and Cisco's tac_plus user guide.
This manual page is incomplete.
| 1 August 2013 |