1 TAC_PLUS Developer's Kit vF4.0.2.alpha
2 --------------------------------------
6 Note: this is a DEVELOPER'S KIT. You probably shouldn't be using this
7 if you don't need source code. Instead, consider using CiscoSecure,
8 Cisco's supported, commercial Tacacs+ daemon.
10 Copyright (c) 1995-1998 by Cisco systems, Inc.
12 Permission to use, copy, modify, and distribute this software for
13 any purpose and without fee is hereby granted, provided that this
14 copyright and permission notice appear on all copies of the
15 software and supporting documentation, the name of Cisco Systems,
16 Inc. not be used in advertising or publicity pertaining to
17 distribution of the program without specific prior permission, and
18 notice be given in supporting documentation that modification,
19 copying and distribution is by permission of Cisco Systems, Inc.
21 Cisco Systems, Inc. makes no representations about the suitability
22 of this software for any purpose. THIS SOFTWARE IS PROVIDED ``AS
23 IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
24 WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
25 FITNESS FOR A PARTICULAR PURPOSE.
27 Please NOTE: None of the TACACS code available here comes with any
28 warranty or support, however, comments or questions may be addressed
29 to Cisco systems via email at the address:
31 customer-service@cisco.com (or more simply)
34 and we will do our best to handle them, though we cannot guarantee a
35 timely response, as this code is UNSUPPORTED. Be sure you've read this
36 user's guide, including the frequently asked questions include in it,
39 Cisco systems also maintains an extensive World Wide Web site at
43 In addition, there are two mailing lists which may be of interest to
46 The first is a mailing list run by spot.Colorado.EDU which discusses
47 many things pertaining to Cisco products. It is not run by Cisco
48 Systems, Inc. and is not part of Cisco's formal service request
49 channels, however, many knowledgeable people, including staff members
50 of Cisco Systems, Inc. voluntarily read and respond on the list.
52 Requests to be added to or deleted from the list at spot.Colorado.EDU,
53 along with other administrative issues concerning it can be sent to:
55 cisco-request@spot.Colorado.EDU
57 There is also a relatively new list called TACPLUS-L, run by
58 disaster.com, created for the purpose of information exchange between
59 TACACS+ Users. It is intended as a supplement to the list at
60 spot.Colorado.EDU, aiding TACACS+ users and prospective users in many
61 issues including but not limited to technical support, bug reports and
62 workarounds, configuration information, recommendations for future
63 versions of TACACS+, and general talk about TACACS+ development,
64 implementation, administration, etc.
66 Please note that neither of these lists is in fact connected with
67 Cisco Systems, Inc. or any of its subsidiaries. Standard etiquette
70 To subscribe to the TACPLUS-L list, send a message to
72 tacplus-l-request@disaster.com
74 In the body of the letter, enter
76 SUBSCRIBE TACPLUS-L your Name
78 to be automatically added, or visit their web page at
79 http://www.disaster.com/tacplus/.
81 Also, Robert Kiessling maintains a TACACS+ FAQ at
82 http://www.easynet.de/tacacs-faq.
84 Lastly, I am always interested in seeing contributed patches, so
85 consider mailing any modifications you make, as context diffs (be sure
86 to indicate with the version your patches are based on), to
87 tacacs-patches@cisco.com. As always, no support is implied, nor any
88 assurance that patches will be made available via ftp (though that is
89 my intent) or incorporated into any code.
94 NAS --- A Network Access Server e.g. a Cisco box, or any other
95 *client* which makes tacacs+ authentication and authorization
96 requests, or generates Tacacs+ accounting packets.
98 Daemon -- A program which services network requests for authentication
99 and authorization, verifies identities, grants or denies
100 authorizations, and logs accounting records.
102 passwd(5) files -- files conforming to Unix password style format, as
103 documented in section 5 of the Unix manuals.
105 AV pairs -- strings of text in the form "attribute=value" sent between a
106 NAS and a tacacs+ daemon as part of the Tacacs+ protocol.
108 Since a NAS is sometimes referred to as a server, and a daemon is also
109 often referred to as a server, the term "server" has been avoided here
110 in favor of the less ambiguous terms "NAS" and "Daemon".
112 TACACS, XTACACS and TACACS+
113 ---------------------------
115 Note that there are now at least 3 versions of authentication protocol
116 that people commonly refer to as "TACACS".
118 The first is ordinary tacacs, which was the first one offered on Cisco
119 boxes and has been in use for many years. The second is an extension
120 to the first, commonly called Extended Tacacs or XTACACS, introduced
123 The third one is TACACS+ (or T+ or tac_plus) which is what is documented
124 here. TACACS+ is NOT COMPATIBLE with any previous versions of tacacs.
126 In addition to the 3 versions of tacacs running on Cisco boxes, the
127 fact that we distribute the source code to the daemon has meant that
128 additional implementations of tacacs daemons have been produced by
129 people who have made modifications to our source code.
133 Tac_plus is known to build and run on the following platforms:
135 AIXv3.2 (using -DAIX and bsdcc. See tac_plus.h for more details).
136 HP/UX A.09.01 using -DHPUX
137 i86 Solaris 2.4 (SUNOS 5.4), using SUNpro SW2.0.1 & -DSOLARIS
138 Sun4 Solaris 2.4 using SUNpro SC3.0.1 and -DSOLARIS
141 MIPS R3K SGI IRIX 4.05F (using -DMIPS)
142 BSDI BSD/386 1.1 (using -DBSDI)
143 FREEBSD 2.0-RELEASE (using -DFREEBSD)
144 LINUX 1.2.8 (using -DLINUX)
146 To build tac_plus, untar the tarfile distribution into a clean
149 tar -xvf tac_plus.tar
151 Edit the top of the Makefile to select the appropriate defaults
152 for your system. Then type
156 The default version can authenticate using its internal database,
157 s/key or passwd(5) style files. Authorization is done via the
158 internal database or via calls to external programs, which the
159 administrator configures.
161 To use S/KEY, you must obtain and build the s/key library (libskey.a)
162 yourself. You can then compile in S/KEY support per the instructions
163 for S/KEY in the Makefile. I got my S/KEY code originally from
164 crimelab.com but now it appears the only source is ftp.bellcore.com. I
165 suggest you try a web search for s/key source code.
167 Note: S/KEY is a trademark of Bell Communications Research (Bellcore).
169 Should you need them, there are routines for accessing password files
170 (getpwnam,setpwent,endpwent,setpwfile) in pw.c.
172 Lastly, you may also need to add lines to your /etc/services file to
173 get tacacs+ to work correctly e.g. something along the lines of:
177 You'll need to consult your system manuals for exact details of how to
180 A NOTE ABOUT ARAP, MSCHAP AND DES
181 ---------------------------------
182 If you have access to a DES library which implements the calls:
189 then you can define DES in tac_plus.h and link tac_plus with your DES
190 library. This is recommended, as it will allow you to process ARAP and MSCHAP
191 requests on your daemon, which is more efficient, and also more secure
192 than processing them on the NAS.
194 If you don't have access to des (which is U.S. export controlled), you
195 can simply leave DES undefined in tac_plus.h. ARAP and MSCHAP
196 authentication will still work, but it will be slightly less
197 efficient, since the NAS will attempt to get the daemon to do the DES
198 calculation before falling back to the alternative of calculating DES
199 on the NAS. It's also slightly less secure, because if someone
200 discovers your encryption key, they can then download ARAP and MSCHAP
201 secrets from your daemon.
203 Note that this issue arises solely because U.S. government regulations
204 currently make it difficult to export the source code for DES outside
205 the US and Canada, which is why it is not included in this
208 Lastly, this limitation of MSCHAP, ARAP and DES has no bearing on the
209 use of des passwords for regular logins. Regular logins also use DES
210 but they do it via the "crypt" system call, which is usually found in
211 a library on the Unix host where you compile your daemon.
213 There are additional restrictions on doing MSCHAP (see the FAQ later
217 ---------------------
219 Tac_plus is configured via a single configuration file. You can create
220 a configuration file from scratch or, if you have passwd(5) and
221 supplementary files from earlier versions of tacacs, you can convert
222 these to configuration file format by running the supplied perl script
225 CONVERTING EXISTING PASSWD(5) FILES
226 -----------------------------------
228 To convert an existing passwd(5) file e.g. one used with an older
229 version of tacacs, use the convert.pl perl script as follows:
231 convert.pl <passwd file> [-g] [<supplementary file>]
233 1). If you have no supplementary file, simply omit it.
235 2). If the groupid field of your passwd file does NOT represent a
236 valid acl number (e.g if it's really a unix passwd file this field is
237 a group id, not an acl number), just omit the -g flag.
239 The rest of this document assumes that you are configuring tac_plus
242 CONFIGURING TAC_PLUS FROM SCRATCH
243 ---------------------------------
245 A configuration file consists of some top-level directives for setting
246 defaults and for setting up the encryption key, followed by a
247 declaration for each user and group you want to configure. Within
248 each user or group declaration, there are declarations for
249 authenticating and authorizing that user.
251 1). Configuring the encryption key
253 If you want tac_plus to encrypt its packets (and you almost certainly
254 *DO* want this, as there can be usernames and passwords contained in
255 these packets), then you must specify an encryption key in the
256 configuration file. The identical key must also be configured on any
257 NAS which communicates with tac_plus.
259 This is done using the statement
261 key = "your key here"
263 NOTE: You only need double quotes on the daemon if your key contains
266 Confusingly, even if your key does contain spaces, you should NEVER
267 use double quotes when you configure the matching key on the NAS.
269 During debugging, it may be convenient to temporarily switch off
270 encryption by not specifying any key. Be careful to remember to
271 switch encryption back on again after you've finished debugging.
273 The current code does not support host-specific keys (left as an
274 exercise to the reader).
276 On the NAS, you also need to configure the *same* key. Do this by
280 tacacs-server key <your key here>
282 COMMENTS IN CONFIGURATION FILES
283 -------------------------------
284 Comments can appear anywhere in the configuration file, starting with
285 the # character and extending to the end of the current line. Should
286 you need to disable this special meaning of the # character, e.g. if
287 you have a password containing a # character, simply enclose the string
288 containing it within double quotes.
290 CONFIGURING USERS AND GROUPS
291 ----------------------------
293 Each user may belong to a group (but only one group). Each group may
294 in turn belong to one other group and so on ad infinitum.
296 Users and groups are declared as follows. Here we declare two users
297 "fred" and "lily", and two groups, "admin" and "staff".
299 Fred is a member of group "admin", and group "admin" is in turn a
300 member of group "staff". Lily is not a member of any group.
303 # user lily is not a member of any group
304 # and has nothing else configured as yet
308 # fred is a member of group admin
313 # group admin is a member of group staff
318 # group staff is not a member of any group
324 In general, when the daemon looks up values e.g. passwords, it will
325 look first to see if the user has her own password. If not, it looks
326 to see if she belongs to a group and if so, whether the group has a
327 password defined. If not, this process continues through the hierarchy
328 of groups (a group can be a member of another group) until a value is
329 found, or there are no more groups.
331 This recursive process occurs for lookups of expiration dates, for
332 pap, arap and chap "secrets", and also for authorization parameters (see
335 A typical configuration technique is thus to place users into groups
336 and specify as many groupwide characteristics in the group declaration
337 as possible. Then, individual user declarations can be used to
338 override the group settings for selected users as needed.
340 CONFIGURING USER AUTHENTICATION
341 -------------------------------
343 User Authentication can be specified separately for PAP, ARAP, CHAP,
344 and normal logins. In addition, a user global authentication method
345 can be given that will be used if a per-protocol method is not
348 PAP, ARAP, CHAP, and global user authentication must be given in clear
351 The following assigns the user mary five different passwords for ARAP,
352 inbound and outbound CHAP, inbound PAP, outbound PAP, and normal login
356 arap = cleartext "arap password"
357 chap = cleartext "chap password"
358 pap = cleartext "inbound pap password"
359 opap = cleartext "outbound pap password"
360 login = des XQj4892fjk
364 The following assigns the user agnes a single password for all the
365 above types of login (except outbound PAP):
368 global = cleartext "Agnes global password"
371 NOTE: you cannot use a global user password for outbound PAP. This is
372 because outbound PAP is implemented by sending the password from the
373 daemon to the NAS. This is a security issue if the TACACS+ key is ever
376 There are 3 ways to authenticate a user for login.
378 1). You can include a DES (or cleartext) password for a user or for a
379 group that s/he is a member of, viz:
383 # this is lily's encrypted DES password. It overrides the admin
385 login = des XQkR21zMB0TDU
389 # fred is a member of group admin. He inherits the group's password
390 # as he does not have his one of his own.
395 # group admin has a cleartext password which all members share
396 # unless they have their own password defined
397 login = cleartext foobar
400 If no password is needed for this user, this can be accomplished with
401 the 'nopassword' option:
407 NOTE: The C program built from generate_passwd.c may be used to
408 hand-generate encrypted passwords, or they may be taken from a Unix
409 passwd (or shadow) file.
411 2). Authentication using passwd(5) files.
413 For selected users, you can perform DES authentication using existing
414 passwd(5) files instead of entering the password into the
415 configuration file directly (though using passwd(5) files is
416 noticeably less efficient for large files).
418 You can specify this behavior per-user, by naming a passwd(5) file in
419 the password declaration (instead of giving a DES password), as
423 # look in file /etc/tac_plus_passwords to authenticate this user
424 login = file /etc/tac_plus_passwords
427 3). Authentication using s/key.
429 If you have successfully built and linked in a suitable s/key library
430 and compiled tac_plus to use s/key, you can then specify that a user
431 be authenticated via s/key, as follows:
437 RECURSIVE PASSWORD LOOKUPS
438 ---------------------------
440 As stated earlier, authentication passwords are looked up recursively:
441 The daemon looks first to see if the user has her own password. If
442 not, it looks to see if she belongs to a group which has a
443 password. This process recurses through the hierarchy of groups (a
444 group can be a member of another group) until a password is found, or
445 there are no more groups.
447 CONFIGURING DEFAULT AUTHENTICATION
448 -----------------------------------
449 By default, an unrecognized user will be denied authentication (NOTE:
450 there is no way to authenticate someone with no username).
452 At the top level of the configuration file, you can set the default
453 authentication to use a passwd(5) file, viz:
455 default authentication = file /etc/passwd
457 The effect of this statement is that if a user does not appear in the
458 configuration file, the daemon will attempt to authenticate the user
459 using passwords from this file i.e. /etc/passwd in this example.
461 If you have passwd(5) files from previous versions of tacacs daemons,
462 this facility allows you to authenticate using the passwd(5) from
463 older versions of tacacs, while you migrate to using the new
466 CONFIGURING EXPIRY DATES
467 ------------------------
468 An entry of the form:
471 expires = "MMM DD YYYY"
472 password = cleartext "bite me"
475 will cause the user's passwords to become invalid, starting on the
476 expiry date. The only valid date format is e.g. "Jan 1 1980". Case is
479 A expiry warning message is sent to the user when she logs in,
480 starting at 14 days before the expiration date.
482 On expiry, the administrator must re-set the expiry date in the
483 configuration file in order to grant continued access. Expiry applies
484 to all password types except "file" passwords.
486 If passwd(5) files are being used for authentication, the "expires"
487 field in the configuration file is not consulted. Instead, the daemon
488 looks at the the "shell" field of the password file entry for a valid
491 If Solaris shadow password files are used for authentication, the
492 "expires" field in the configuration file is not consulted. The expiry
493 field from the shadow password file (if it exists) is used as the
496 CONFIGURING AUTHENTICATION ON THE NAS
497 -------------------------------------
499 On the NAS, to configure login authentication on all lines (including
500 vty and console lines)
503 aaa authentication login default tacacs+
505 NOTE: As soon as you issue this command, you will no longer be able to
506 create new logins to your NAS without a functioning tacacs+ daemon
507 appropriately configured with usernames and password, so make sure you
510 As a safety measure while setting up, we suggest you configure an
511 enable secret and make it the last resort authentication method, so
512 if your tacacs+ daemon fails to respond you will be able to use the
513 NAS enable password to login. To do this, configure:
516 aaa authentication login default tacacs+ enable
518 If all else fails, and you find yourself locked out of the NAS due to
519 a configuration problem, the section on "recovering from lost
520 passwords" on Cisco's CCO web page will help you dig your way out.
522 CONFIGURING ENABLE PASSWORDS
523 ----------------------------
525 The default privilege level for an ordinary user on the NAS is usually
526 1. When a user enables, she can reset this level to a value between 0
527 and 15 by using the NAS "enable" command. If she doesn't specify a
528 level, the default level she enables to is 15.
530 You can enable via tacacs+ e.g. by configuring on the NAS:
532 aaa authentication enable default tacacs+
534 then whenever you attempt to enable, an authentication request is sent
535 with the special username $enab<n>$ where <n> is the privilege level
536 you are attempting to enable to.
538 (Note: in order to be compatible with earlier versions of tacacs, when
539 the requested enable level is 15, the daemon will also try the
540 username $enable$ before trying username $enab15$).
542 For example, with the above declaration, in order to enable on the
543 NAS, you need a user declaration like this one, on the daemon:
546 login = cleartext "the enable password for level 15"
549 Note: Be aware that this does have the side effect that you now have a
550 user named $enab15$ who can then login to your NAS if she knows the
553 Here is a similar declaration allowing users to enable to level 4:
556 login = des bsoF4OivQCY8Q
559 CONFIGURING AUTHORIZATION
560 -------------------------
562 Authorization must be configured on both the NAS and the daemon to
563 operate correctly. By default, the NAS will allow everything until you
564 configure it to make authorization requests to the daemon.
566 On the daemon, the opposite is true: The daemon will, by default, deny
567 authorization of anything that isn't explicitly permitted.
569 Authorization allows the daemon to deny commands and services
570 outright, or to modify commands and services on a per-user
571 basis. Authorization on the daemon is divided into two separate parts:
572 commands and services.
577 Exec commands are those commands which are typed at a Cisco exec
578 prompt. When authorization is requested by the NAS, the entire command
579 is sent to the tac_plus daemon for authorization.
581 Command authorization is configured by specifying a list of
582 egrep-style regular expressions to match command arguments (see the
583 supplied man page, regexp.3, for a full description of regular
584 expressions) and an action which is "deny" or "permit".
586 The following configuration example permits user Fred to run the
589 telnet 131.108.13.<any number> and
590 telnet 128.<any number>.12.3 and
593 All other commands are denied (by default).
598 # permit specified telnets
599 permit 131\.108\.13\.[0-9]+
600 permit 128\.[0-9]+\.12\.3
603 # permit show commands
608 NOTE: If an argument list you specify contains spaces or tabs, you
609 must enclose it in double quotes.
611 The command and arguments which the user types gets matched to the
612 regular expressions you specify in the configuration file (in order of
613 appearance). The first successful match performs the associated
614 action (permit or deny). If there is no match, the command is denied
617 Conversely, the following configuration example can be used to deny
620 telnet 131.108.13.<any number>
622 and permit all other arguments, since the last line will match any
623 argument list. All other commands and services are permitted due to
624 the "default service = permit" clause.
626 Note: the default statement must be the first in the user clause
629 default service = permit
631 # allow all fred's telnet commands except to 131.108.13.*
632 deny 131\.108\.13\.[0-9]+
637 Note: Matches are not anchored, so "deny 131.108.13.[0-9]+" matches
638 anywhere in the command. To anchor the match, use ^ at the beginning
639 of the regular expression.
641 Note: When a command has multiple arguments, users may enter them in
642 many different permutations. It can be cumbersome to create regular
643 expressions which will reliably authorize commands under these
644 conditions, so administrators may wish to consider other methods of
645 performing authorization e.g. by configuring NAS-local privileged
646 enable levels on the NAS itself.
651 For command authorization, the Cisco NAS expands all commands to their
652 full names e.g. when you type "config t" on the NAS, this will be
653 expanded to "configuration terminal" before being sent to the daemon
654 so that you don't need to list all the possible contractions of a
657 CONFIGURING DEFAULT AUTHORIZATION
658 ---------------------------------
660 There are 3 places where defaults for authorization may be
661 configured. Unless specified to the contrary, the default is always to
664 1). To override the default denial of authorization for users who are
665 not explicitly listed in the configuration file, the ersatz user
666 DEFAULT, if defined, can be used for authorizing such users, viz:
668 default authentication = file /etc/passwd
671 service = ppp protocol = ip {
676 In this example, users who do not appear elsewhere will be
677 authenticated via the /etc/passwd file, and authorized by the contents
678 of the user = DEFAULT entry.
680 Note: For backward compatibility, the directive,
682 default authorization = permit
684 may still be specifed at the top level of the configuration file. This
685 overrides the default denial of authorization for users who are not
686 explicitly listed in the configuration file, permitting all
687 authorization requests for such users.
689 2). At the user level i.e. inside the braces of a user declaration,
690 the default for a user who doesn't have a service or command
691 explicitly authorized is to deny that service or command. The
692 following directive will permit the service or command by default
696 default service = permit
699 NOTE: This directive must appear first inside the user declaration.
701 3). At the service authorization level i.e. inside the braces of a
702 service declaration, arguments in an authorization request are
703 processed according to the algorithm described later. Some actions
704 when authorizing services (e.g. when matching attributes are not
705 found) depend on how the default is configured. The following
706 declaration changes the default from deny to permit for this user and
711 default attribute = permit
715 NOTE: This directive must appear before any others inside the service
718 NOTE: for command authorization (as opposed to service authorization
719 being discussed here), you specify deny .* or permit .* as the last
720 line of the regular expression matches to create default behavior.
722 AUTHORIZING EXEC STARTUP
723 -------------------------
725 If you authorize some exec commands, you implicitly agree to allow
726 that user to start an exec (it doesn't make sense to permit exec
727 commands if an exec can't be started to run those commands)
729 In addition to agreeing to allow an exec to start, you can supply some
730 parameters whenever an exec starts e.g. an autocommand, a dialback
731 string or a connection access list (acl).
733 In the example below, when an exec is started on the NAS, an acl of 4
734 will be returned to the NAS:
738 # this following line permits an exec to start and permits
739 # all commands and services by default
741 default service = permit
744 # When an exec is started, its connection access list will be 4.
745 # It also has an autocmd.
747 autocmd = "telnet foobar"
751 # allow all fred's telnet commands except telnet to 131.108.13.*
752 deny 131\.108\.13\.[0-9]+
757 NOTE: specifying an autocommand, or any other exec services, is part
758 of EXEC AUTHORIZATION. For it to work, you must also configure exec
759 authorization on your NAS e.g.
761 aaa authorization exec tacacs+
764 AUTHORIZING EXEC, SLIP, PPP and ARAP SERVICES
765 ----------------------------------------------
767 Authorizing exec, slip, PPP and arap services is done quite
768 differently from command authorization.
770 When authorizing these services, the NAS sends a request containing a
771 number of attribute-value (AV) pairs, each having the form
775 (Note: during debugging, you may see AV pairs whose separator
776 character is a "*" instead of a "=" sign. This is to signify that the
777 value in a pair is optional. An "=" sign indicates a mandatory
778 value. A "*" denotes an optional value).
780 e.g. a user starting ppp/ip using an address of 131.108.12.44 would
781 generate a request with the following AV pairs:
787 You can use the NAS debugging command
789 debug aaa authorization
791 to see what authorization AV pairs are being used by the NAS. Note: If
792 you are not on the router console, you will also need to issue a
793 'terminal monitor' command to see debug output.
795 THE AUTHORIZATION PROCESS
796 -------------------------
798 Authorizing a single session can result in multiple requests being
799 sent to the daemon. For example, in order to authorize a dialin ppp
800 user for IP, the following authorization requests will be made from
803 1). An initial authorization request to startup ppp from the exec,
804 using the AV pairs service=ppp, protocol=ip, will be made (Note: this
805 initial request will be omitted if you are autoselecting ppp, since
806 you won't know the username yet).
808 This request is really done to find the address for dumb PPP (or SLIP)
809 clients who can't do address negotiation. Instead, they expect you to
810 tell them what address to use before PPP starts up, via a text message
811 e.g. "Entering PPP. Your address is 1.2.3.4". They rely on parsing
812 this address from the message to know their address.
814 2). Next, an authorization request is made from the PPP subsystem to
815 see if ppp's LCP layer is authorized. LCP parameters can be set at
816 this time (e.g. callback). This request contains the AV pairs
817 service=ppp, protocol=lcp.
819 3). Next an authorization request to startup ppp's IPCP layer is made
820 using the AV pairs service=ppp, protocol=ipcp. Any parameters returned
821 by the daemon are cached.
823 4). Next, during PPP's address negotiation phase, each time the remote
824 peer requests a specific address, if that address isn't in the cache
825 obtained in step 3, a new authorization request is made to see if the
826 peers requested address is allowable. This step can be repeated
827 multiple times until both sides agree on the remote peer's address or
828 until the NAS (or client) decide they're never going to agree and they
829 shut down PPP instead.
831 As you can see from the above, a program which plans to handle
832 authorization must be able to handle a variety of requests and respond
835 AUTHORIZATION RELIES ON AUTHENTICATION
836 --------------------------------------
838 Since we pretty much rely on having a username in authorization
839 requests to decide which addresses etc. to hand out, it is important
840 to know where the username for a PPP user comes from. There are
841 generally 2 possible sources
843 1). You force the user to authenticate by making her login to the exec
844 and you use that login name in authorization requests. This username
845 isn't propagated to PPP by default. To have this happen, you generally
846 need to configure the "if-needed" method, e.g.
848 aaa authentication login default tacacs+
849 aaa authentication ppp default if-needed
852 2). Alternatively, you can run an authentication protocol, PAP or CHAP
853 (CHAP is much preferred), to identify the user. You don't need an
854 explicit login step if you do this (so it's the only possibility if
855 you are using autoselect). This authentication gets done before you
856 see the first LCP authorization request of course. Typically you
857 configure this by doing:
859 aaa authentication ppp default tacacs+
861 ppp authentication chap
863 If you omit either of these authentication schemes, you will start to
864 see authorization requests in which the username is missing.
866 CONFIGURING SERVICE AUTHORIZATION
867 ---------------------------------
869 A list of AV pairs is placed in the daemon's configuration file in
870 order to authorize services. The daemon compares each NAS AV pair to
871 its configured AV pairs and either allows or denies the service. If
872 the service is allowed, the daemon may add, change or delete AV pairs
873 before returning them to the NAS, thereby restricting what the user is
876 The complete algorithm by which the daemon processes its configured
877 AV pairs against the list the NAS sends, is given below.
879 The Authorization Algorithm
880 ---------------------------
882 Find the user (or group) entry for this service (and protocol), then
883 for each AV pair sent from the NAS:
885 If the AV pair from the NAS is mandatory:
887 a). look for an exact attribute,value match in the user's
888 mandatory list. If found, add the AV pair to the output.
890 b). If an exact match doesn't exist, look in the user's
891 optional list for the first attribute match. If found, add the
892 NAS AV pair to the output.
894 c). If no attribute match exists, deny the command if the
895 default is to deny, or,
897 d). If the default is permit, add the NAS AV pair to the
900 If the AV pair from the NAS is optional:
902 e). look for an exact attribute,value match in the user's
903 mandatory list. If found, add DAEMON's AV pair to output.
905 f). If not found, look for the first attribute match in the
906 user's mandatory list. If found, add DAEMONS's AV pair to output.
908 g). If no mandatory match exists, look for an exact
909 attribute,value pair match among the daemon's optional AV
910 pairs. If found add the DAEMON's matching AV pair to the
913 h). If no exact match exists, locate the first attribute match
914 among the daemon's optional AV pairs. If found add the
915 DAEMON's matching AV pair to the output.
917 i). If no match is found, delete the AV pair if the default is
920 j). If the default is permit add the NAS AV pair to the output.
922 k). After all AV pairs have been processed, for each mandatory
923 DAEMON AV pair, if there is no attribute match already in the
924 output list, add the AV pair (but add only ONE AV pair for each
925 mandatory attribute).
927 RECURSIVE AUTHORIZATION
928 -----------------------
930 Remember that authorization is also recursive over groups, in the same
931 way that password lookups are recursive. Thus, if you place a user in
932 a group, the daemon will look in the group for authorization
933 parameters if it cannot find them in the user declaration.
938 key = "your key here"
941 login = des mEX027bHtzTlQ
942 name = "Fred Flintstone"
943 member = administrators
944 expires = "May 23 2005"
945 arap = cleartext "Fred's arap secret"
946 chap = cleartext "Fred's chap secret"
949 # When Fred starts an exec, his connection access list is 5
952 # We require this autocmd to be done at startup
953 autocmd = "telnet foo"
956 # All commands except show system are denied for Fred
959 # Fred can run the following show command
965 service = ppp protocol = ip {
966 # Fred can run ip over ppp only if he uses one
967 # of the following mandatory addresses. If he supplies no
968 # address, the first one here will be mandated
975 # Fred's mandatory input access list number is 101
978 # We will suggest an output access list of 102, but the NAS may
979 # choose to ignore or override it
986 # Fred can run slip. When he does, he will have to use
987 # these mandatory access lists
996 # Wilma has no password of her own, but she's a group member so
997 # she'll use the group password if there is one. Same for her
998 # password expiry date
1005 # group members who don't have their own login password will be looked
1008 login = file /etc/passwd
1010 # group members who have no expiry date set will use this one
1012 expires = "Jan 1 1997"
1016 USING PROGRAMS TO DO AUTHORIZATION
1017 ----------------------------------
1019 There are some limitations to the authorization that can be done using
1020 a configuration file. The main ones are that you're constrained by the
1021 algorithm the daemon uses, and that the configuration is basically
1022 static, so if you're trying to use it to allocate dynamic things (such
1023 as addresses from a pool) that vary over time, you need another
1026 One solution is to arrange for the daemon to call your own
1027 user-supplied programs to control authorization. These "callouts"
1028 permit almost complete control over authorization, allowing you to
1029 read all the fields in the authorization packet sent by the NAS
1030 including all its AV pairs, and to set authorization status and send a
1031 new set of AV pairs to the NAS in response.
1033 USING AV PAIRS FOR AUTHORIZATION
1034 --------------------------------
1036 During authorization, the NAS sends an authorization request packet
1037 containing various fields of interest and a set of AV pairs (see the
1038 tacacs+ protocol specification for a list of fields and pairs).
1040 Fields from the authorization packet can be supplied to the programs
1041 you call on their command line, by using the appropriate dollar
1042 variables in the configuration file (see below).
1044 AV pairs from the authorization packet are fed to the program's
1045 standard input, one per line. The program is expected to process the
1046 AV pairs and write them to its standard output, one per line. What
1047 happens then is determined by the exit status of the program.
1049 NOTE: AV pairs are text strings with the format
1050 attribute=value. Unlike the configuration file which allows spaces
1051 when specifying AV pairs, there should be no spaces surrounding the
1052 "=" sign when using the programmatic interface.
1054 CALLING SCRIPTS BEFORE AUTHORIZATION
1055 ------------------------------------
1057 You can specify a per-user program to be called before any other
1058 attempt to authorize is made by using a "before" clause e.g.
1061 before authorization "/usr/bin/pre_authorize $user $port $address"
1064 The AV pairs sent from the NAS will be supplied to this program's
1065 standard input, one pair per line.
1067 Fields from the initiating authorization packet which the NAS sends to
1068 the daemon can also be passed to the program by using dollar variables
1069 in the command line. A complete list of available variables is as
1070 follows (consult the API specification for more details).
1075 address -- Nac address (remote user location)
1076 priv -- privilege level (a digit, 0 to 15)
1077 method -- (a digit, 1 to 4)
1078 type -- (a digit, 1 to 4)
1079 service -- (a digit, 1 to 7)
1080 status -- (pass, fail, error, unknown)
1082 Unrecognized variables will appear as the string "unknown".
1084 If the program returns a status of 0, authorization is unconditionally
1085 permitted. No further processing is done on this request and no AV
1086 pairs are returned to the NAS.
1088 If the program returns a status of 1, authorization is unconditionally
1089 denied. No further processing is done on this request and no AV pairs
1090 are returned to the NAS.
1092 If the program returns a status of 2, authorization is permitted. The
1093 program is expected to modify the AV pairs that it receives on its
1094 standard input (or to create entirely new ones) and to write them, one
1095 per line, to its standard output. The new AV pairs will be sent to the
1096 NAS with a status of AUTHOR_STATUS_PASS_REPL. No further processing
1097 takes place on this request.
1099 If the program returns a status of 3, authorization is denied, but all
1100 attributes returned by the program via stdout are returned to the
1101 NAS. Also, whatever the program returns on stderr is placed into the
1102 server-msg field and returned to the NAS as well.
1104 Any other status value returned from the program will cause an error
1105 to be returned to the NAS.
1107 Note that a status of 2 is not acceptable when doing command
1110 CALLING PROGRAMS AFTER AUTHORIZATION
1111 ------------------------------------
1113 You can specify a per-user program to be called after authorization
1114 processing has been carried out by the daemon (but before the
1115 authorization status and AV pairs have been transmitted to the NAS).
1117 The program can optionally modify the AV pairs being sent back to the
1118 NAS and change the authorization status if required.
1121 # call /usr/bin/post_authorize passing it the username, port
1122 # and current authorization status.
1123 after authorization "/usr/bin/post_authorize $user $port $status"
1126 The AV pairs resulting from the authorization algorithm that the
1127 daemon proposes to return to the NAS, are supplied to the program on
1128 standard input, one AV pair per line, so they can be modified if
1131 Fields from the incoming authorization packet which the NAS sent to
1132 the daemon can also be passed to the program on its command line by
1133 specifying dollar variables in the command line (see previous
1136 The program is expected to process the AV pairs and write them to its
1137 standard output, one per line. What happens then is determined by the
1138 exit status of the program:
1140 If the program returns a status of 0, authorization continues as if
1141 the program had never been called. Use this if e.g. you just want a
1142 program to send mail when an authorization occurs, without otherwise
1143 affecting normal authorization.
1145 If the program returns a status of 1, authorization is unconditionally
1146 denied. No AV pairs are returned to the NAS. No further authorization
1147 processing occurs on this request.
1149 If the program returns a status of 2, authorization is permitted and
1150 any AV pairs returned from the program on its standard output are sent
1151 to the NAS in place of any AV pairs that the daemon may have
1154 Any other value will cause an error to be returned the the NAS by the
1157 WARNINGS AND CAUTIONS
1158 ---------------------
1160 Customers attempting to write authorization scripts will find the NAS
1161 debugging command "debug aaa authorization" invaluable.
1163 Pre and post authorization programs are invoked by handing the command
1164 line to the Bourne shell. On many Unix systems, if the shell doesn't
1165 find the specified program it returns a status of one, which denies
1166 authorization. However, at least one Unix system (BSDI) returns a
1167 status code of 2 under these circumstances, which will permit
1168 authorization, and probably isn't what you intended.
1170 Note also that if your program hangs, the authorization will time out
1171 and return an error on the NAS, and you'll tie up a process slot on
1172 the daemon host, eventually running out of resources. There is no
1173 special code to detect this in the daemon.
1175 Unless you make special arrangements, the daemon will run as root and
1176 hence the programs it invokes will also run as root, which is a
1177 security weakness. It is strongly recommended that you use absolute
1178 pathnames when specifying programs to execute, and that you use the
1179 Makefile options TAC_PLUS_USERID and TAC_PLUS_GROUPID so that the
1180 daemon is not running as root when calling these programs,
1182 The daemon communicates with pre and post authorization programs over
1183 a pair of pipes. Programs using the standard i/o library will use full
1184 buffering in these circumstances. This shouldn't be a problem for most
1185 programs, since they'll read AV pairs till they see end of file on
1186 input, and they'll flush all output when they exit.
1188 Note that when avpairs containing spaces are listed in the
1189 configuration file, you need to enclose them in double quotes so that
1190 they are parsed correctly. Avpairs which are returned via standard
1191 output do not need delimiters and so should not be enclosed in double
1194 CONFIGURING AUTHORIZATION ON THE NAS
1195 ------------------------------------
1197 If authorization is not explicitly configured on the NAS, no
1198 authorization takes place i.e. effectively, everything is
1199 permitted. Note that this is the converse of what happens on the
1200 daemon, where anything not explicitly permitted is denied by default.
1202 To configure command authorization on the NAS, issue the following NAS
1203 configuration commands:
1205 aaa authorization commands 1 tacacs+
1206 aaa authorization commands 15 tacacs+
1209 This will make the NAS send tacacs+ requests for all level 1 (ordinary
1210 user) and level 15 (privileged level) commands on all lines/interfaces.
1212 NOTE: As soon as you configure the above on your NAS, you will only be
1213 permitted to execute NAS commands which are permitted by your tacacs+
1214 daemon. So make sure you have configured, on the daemon, an
1215 authenticated user who is authorized to run commands, or you will be
1216 unable to do much on the NAS after turning on authorization.
1218 Alternatively, or in addition, you may also want to configure the
1221 aaa authorization commands 1 tacacs+ if-authenticated
1223 This will use tacacs+ authorization for level 1 (user-level commands)
1224 but if problems arise, you can just switch off the tacacs+ server and
1225 authorization will then be granted to anyone who is authenticated.
1227 The following daemon configuration should be sufficient to ensure that
1228 you can always login as username "admin" (with a suitable password)
1229 and run any command as that user:
1232 default service = permit
1233 login = des kppPfHq/j6gXs
1240 There is only one configurable accounting parameter -- the accounting
1241 file name. All accounting records are written, as text, to this
1242 filename. The filename is configured as follows at the top-level of
1243 the configuration file:
1245 accounting file = <filename>
1247 Since accounting requests occur (and are serviced) asynchronously, it
1248 is necessary to lock the accounting file so that two writers don't
1249 simultaneously update it. The daemon uses the fcntl call to do this
1250 locking, so it is recommended that the accounting file reside on a
1251 local filesystem. Although fcntl locking over NFS is supported on some
1252 Unix implementations, it is notoriously unreliable. Even if your
1253 implementation is reliable, locking is likely to be extremely
1254 inefficient over NFS.
1259 To get accounting records equivalent to previous versions of tacacs,
1260 the following is sufficient. "Stop" records contain elapsed time for
1261 connections and exec sessions.
1263 aaa accounting network stop-only tacacs+
1264 aaa accounting exec stop-only tacacs+
1267 CONFIGURING CALLBACK WITH TACACS+
1268 ---------------------------------
1270 Note: Callback is available only in IOS 11.1 and later, and can only
1271 be controlled via Tacacs+ for ASYNC lines. ISDN callback can be
1272 configured on the NAS but cannot be controlled via AAA.
1274 Here is an example of AAA configuration (with exec and network
1275 accounting enabled):
1280 tacacs-server host XX.XX.XX.XX
1281 tacacs-server key fookey
1282 aaa accounting exec wait-start tacacs+
1283 aaa accounting network wait-start tacacs+
1285 ! Example of AAA configuration for Exec:
1286 aaa authentication login execcheck tacacs+
1287 aaa authorization network tacacs+
1288 service exec-callback
1291 login authentication execcheck
1293 ! Example of AAA configuration for ARAP:
1294 aaa authentication arap arapcheck tacacs+
1295 aaa authorization network tacacs+
1299 arap authentication arapcheck
1301 ! Example of AAA-specific configuration for PPP callback:
1303 aaa authentication ppp pppcheck tacacs+
1304 aaa authorization network tacacs+
1307 ppp authentication chap pppcheck
1310 Daemon configuration:
1312 Example of remote TACACS+ server CONFIG file entry for username `foobar':
1315 arap = cleartext AAAA
1316 login = cleartext LLLL
1317 chap = cleartext CCCC
1318 pap = cleartext PPPP
1319 opap = cleartext OOOO
1320 service = ppp protocol = lcp {
1321 callback-dialstring=123456
1324 callback-dialstring=2345678
1327 callback-dialstring=3456789
1336 DEBUGGING CONFIGURATION FILES
1337 -----------------------------
1339 When creating configuration files, it is convenient to check their
1340 syntax using the -P flag to tac_plus e.g.
1342 tac_plus -P -C <config file name>
1344 will syntax check the configuration file and print any error messages
1347 DEBUGGING A RUNNING SERVER
1348 --------------------------
1350 There is a myriad of debugging values that can be used in conjunction
1351 with the -d flag to produce debugging output in /var/log/tac_plus.log.
1353 For example, starting the daemon with
1355 tac_plus -C CONFIG -d 16
1357 will put authentication debugging into /var/log/tac_plus.log. You can
1358 view this information by using the tail command.
1360 tail -f /var/log/tac_plus.log
1362 See the man page for more information.
1364 CHANGING CONFIGURATIONS
1365 -----------------------
1367 To change a configuration file, you must edit the configuration file
1368 and then send the daemon a SIGUSR1. This will cause it to reinitialize
1369 itself and re-read the configuration file.
1371 On startup, tac_plus creates the file /var/run/tac_plus.pid , if possible,
1372 containing its process id. If you invoke the daemon so that it listens
1373 on a non-standard port, the file created is /var/run/tac_plus.pid.<port>
1374 instead, where <port> is the port number the daemon is listening on.
1376 Assuming you are listening on the default port 49, something like the
1377 following should work:
1379 # kill -USR1 `cat /var/run/tac_plus.pid`
1381 It's a good idea to check that the daemon is still running after
1382 sending it a SIGUSR1, since a syntactically incorrect configuration
1383 file will cause the daemon to die.
1385 NOTE: The perl script generate_passwd.pl may be used to hand-generate
1386 encrypted passwords, or they may be taken from a Unix passwd file.
1388 FREQUENTLY ASKED QUESTIONS
1389 --------------------------
1390 Q). Does T+ required a working DNS?
1392 A). As distributed, whenever a START packet arrive, the daemon makes a
1393 call to getpeername to find out the name of the requestor. Depending
1394 entirely on how your Unix host is set up, this may make DNS
1395 queries. If this is a problem, comment out the code in tac_plus.c
1396 which does this, and just use ip addresses instead of host names.
1398 Q). Is the "name" field used for anything
1400 A). No. It's purely for documentation. I had once thought it might be
1401 useful when outputting error messages, and that you might need the
1402 information if you converted a passwd(5) style file, but no use is
1403 currently made of the field.
1405 Q). Why do I get PPP authorization failures because of "no username in
1406 request" when I've already logged in and authenticated?
1408 A). With "aaa authentication PPP default tacacs+", the ppp
1409 authentication overrides the earlier login authentication. If the ppp
1410 authentication fails, the username ends up blank. Changing the config
1411 to "aaa authentication ppp default if-needed tacacs+" fixes this
1414 Q). I'm sure I configured it correctly, but accounting still doesn't
1417 A). You will find that although you can configure accounting in 10.3,
1418 and it outputs debug messages, it doesn't send any accounting
1419 packets. This is because Accounting only works from 11.0 onwards.
1421 Q). Does TACACS+ use a database instead of a flat (/etc/passwd like)
1422 file to decrease search times, say if we are talking about a large
1423 database of 40,000 users?
1425 A). The TACACS+ authentication database is held internally as a hash
1426 table. This makes lookup times fast and fairly linear, at the expense
1427 of making the server use potentially large amounts of memory space.
1428 NOTE: If you specify that the server uses passwd(5) files for
1429 authentication, then you don't get this speed benefit, but you save
1432 If you're willing to write the code, it should be a relatively simple
1433 matter to interface the code to a database scheme e.g. unix dbm files,
1434 or some proprietary database package, if you wish.
1436 Q). Is there any way to avoid having clear text versions of the
1437 ARAP and CHAP secrets in the configuration file?
1439 CHAP and ARAP require that the server knows the cleartext password (or
1440 equivalently, something from which the server can generate the
1441 cleartext password). Note that this is part of the definition of CHAP
1442 and ARAP, not just the whim of some Cisco engineer who drank too much
1443 coffee late one night.
1445 If we encrypted the CHAP and ARAP passwords in the database, then we'd
1446 need to keep a key around so that the server can decrypt them when
1447 CHAP or ARAP needs them. So this only ends up being a slight
1448 obfuscation and not much more secure than the original scheme.
1450 In extended TACACS, the CHAP and ARAP secrets were separated from the
1451 password file because the password file may be a system password file
1452 and hence world readable. But with TACACS+'s native database, there
1453 is no such requirement, so we think the best solution is to
1454 read-protect the files. Note that this is the same problem that a
1455 kerberos server has. If your security is compromised on the kerberos
1456 server, then your database is wide open. Kerberos does encrypt the
1457 database, but if you want your server to automatically restart, then
1458 you end up having to "kstash" the key in a file anyway and you're back
1459 to the same security problem.
1461 So storing the cleartext password on the security server is really an
1462 absolute requirement of the CHAP and ARAP protocols, not something
1465 We could have chosen a scheme where the NAS sends the challenge
1466 information to the TACACS+ daemon and the daemon uses the cleartext
1467 password to generate the response and returns that, but that means
1468 that we must include specific protocol knowledge into the protocol for
1469 both ARAP and CHAP and we would have to update the protocol every time
1470 a new authentication protocol is added. Hence we decided to go with
1471 the SENDPASS mechanism.
1473 Note that the above doesn't apply to PAP. You can keep an inbound PAP
1474 password des-encrypted, since all you need to do with it is verify
1475 that the password the principal gave you is correct.
1477 Q). How is the typical login authentication sequence done?
1479 A). NAS sends START packet to daemon
1480 Daemon send GETUSER containing login prompt to NAS
1481 NAS prompts user for username
1482 NAS sends pkt to daemon
1483 Daemon sends GETPASS containing password prompt to the NAS
1484 NAS prompts user for password
1485 NAS sends pkt to daemon
1486 Daemon sends accept, reject or error to NAS
1489 Q). Is there a GUI for the configuration file?
1490 A). No. Use your favourite text editor.
1493 Q). What does "default service = permit" really do?
1495 A). When a request comes in to authorize exec startup, or ppp (with
1496 protocol lcp, ip, ipx), or slip, or arap or a specific command, the
1497 daemon looks for a matching declarations for the user (or groups the
1498 user is a member of).
1500 For exec startup, it looks for a "service=exec" OR any command
1503 For ppp, it looks for a "service=ppp" and "protocol=(one of lcp, ip,
1506 For slip there must be a "service=slip" and for arap a "service=arap"
1509 For specific commands, there must be a matching cmd=<cmdname>.
1511 If these aren't found, authorization will fail, *unless* you say
1512 "default service = permit".
1514 Q). How do I make PAP work?
1516 A). Avoid using PAP if possible since it's not very secure. If you
1517 *must* use it, PAP passwords may be specified along with arap and chap
1518 passwords for each user. Note that the details of this changed in
1519 version 3.0 and onwards.
1521 For outbound PAP, where you are forced to send a password to the
1522 remote host to identify yourself, there is now a separate "opap"
1525 opap = cleartext OOOO
1527 You use this to set the outbound PAP password. It must be a cleartext
1530 NOTE: It is very bad practice to use an outbound PAP password that is
1531 the same as any of your inbound passwords. For this reason, a "global"
1532 password does not apply to outbound PAP, only to inbound PAP,
1533 bidirectional CHAP and ARAP.
1535 Before 3.0, PAP logins were treated like ordinary user logins, so you
1536 needed to declare a user in the Daemon configuration file whose name
1537 was typically the remote hostname (or user), with a login password, in
1538 order to process the PAP request.
1540 Q). How can I deny some one from telneting from a commserver by ip
1541 address only. i.e. when command is 10.0.1.6 rather than telnet
1544 A). The best way to restrict telnet access is by applying an outbound
1545 access list via the access class command (or equivalently, via the
1546 "acl" avpair). The NAS configuration command "access-class <n> out"
1547 for example applies a pre-defined standard IP access list (where n is
1548 a number from 1 through 99) that governs telnet access from a NAS.
1550 E.g. the following configuration commands permit outgoing Telnet
1551 access from line 1 on the NAS *only* to hosts on network 192.85.55.0:
1553 access-list 12 permit 192.85.55.0 0.0.0.255
1557 Note: you must define "access-list 12 permit 192.85.55.0 0.0.0.255" on
1558 the NAS. Only then can you use the acl avpair to apply it to a line
1559 that a user dials in on.
1561 Alternatively, you can try configuring "transport preferred none" on
1562 the lines in question. This will force a user to always type "telnet
1563 10.0.1.6" in order to telnet out from the NAS. Then you can apply
1564 command authorization to this command to restrict it.
1566 Q). I have an autocommand configured in the NAS-local database and I'm
1567 using "aaa authentication local-override". The autocommand doesn't
1568 work, but the username/password does. Why?
1570 A). The "local-override" only applies to the authentication portion of
1571 the local database, so if you want an autocommand for this user, you
1574 aaa authorization exec local if-authenticated
1576 This will use the local DB entry if one exists, allow authenticated
1577 users otherwise, or fail.
1579 We don't have a "aaa authorization local-override" like we do for
1580 authentication. Unlike authentication, the local method for
1581 authorization is sort of equivalent to a local-override.
1583 Q). Can tacacs+ only be enabled on a global basis? I want to
1584 selectively turn it on for, e.g. only modem-connected lines. How do I
1587 A). You turn tacacs+ ON on a global basis, but you can then change the
1588 behavior of individual lines to whatever you want, e.g.
1590 aaa authentication login default tacacs+ none
1591 aaa authentication login oldstyle line
1592 aaa authentication login none none
1594 login authentication default
1596 login authentication oldstyle
1598 login authentication none
1600 Note that unfortunately, you can't (yet) apply authorization
1601 differently to selected lines and interfaces.
1603 Q). I have leased lines running PPP, and AAA authorization is also
1604 configured, so the authorization on the leased lines fails. What should
1607 A). Since you can't (yet) configure authorization on a per-line basis,
1608 you have to turn on authentication on the leased lines running PPP and
1609 configure your T+ server so that it will authorize these lines
1612 A more demanding alternative is to modify the TACACS+ server source code
1613 to allow any authorizations coming in from the port "SerialXXX" to
1616 A third possibility is to not use PPP on those lines, e.g. use HDLC
1617 instead. HDLC doesn't require authentication or authorization.
1619 Q). What are the memory recommendations for TACACS+?
1621 A). Unless you're using passwd style files, TACACS+ holds entries in
1622 hash tables in memory. The overhead is modest e.g. each user entry
1623 occupies 72 bytes, plus space for strings like username and password
1624 etc. Access time should thus be pretty constant regardless of number
1625 of users. On a sparc 2, a config file containing 2000 users requires
1628 Q). How many users will a TACACS+ server support? What happens when
1629 the maximum is exceeded?
1631 There are 2 issues. The first is that each entry in the config file
1632 occupies memory (swap space) so you could run out of swap space either
1633 starting up the daemon or when it forks to answer incoming requests
1634 (see above). If this happens, the daemon will drop the connection
1635 which should appear as an error to the NAS) and the logfile will
1636 contain appropriate error messages. The solution is usually to add
1637 more disk space for swapping.
1639 The second issue is speed: Using config files containing 75,000 user
1640 entries, I'm seeing about 3 authentications per second on a sparc 2
1641 without noticeable performance impact, though I haven't benchmarked
1644 So more than about 3 authentications per second on this platform will
1645 result in users seeing delays and having to wait for prompts. The
1646 usual solution to this is to add more daemons to spread the load out.
1648 Q). How many characters may a TACACS+ Username and Password contain?
1650 A). The short answer is 31 bytes of username, with up to 254 bytes of
1651 password if they are cleartext (8 bytes if passwords are des
1654 The long answer is that the Cisco NAS allocates a buffer of 1024
1655 bytes, so this is the maximum you can type in, in response to a NAS
1658 But the protocol spec allows a username or password length field of
1659 just one byte in an authentication packet, so only the first 255 of
1660 these characters can be sent to the daemon.
1662 Then, the API spec states that the username in the identity structure
1663 on the daemon is 32 bytes long, so only the first 31 bytes of username
1664 will be copied from the authentication packet into this structure,
1665 which is then null-terminated.
1667 The password, on the other hand, is copied into malloc'ed memory, so
1668 it can still be up to 255 characters long.
1670 Now if it's a des encrypted password, then only the first 8 bytes are
1671 significant, per the common unix implementations of crypt.
1673 Lastly, there is also the question of how long a username/password can
1674 be configured in the daemon configuration file. The answer is given by
1675 the value of MAX_INPUT_LINE_LEN, currently set to 255, which
1676 determines the length of the longest string you can enter in the
1679 Q). What is the format of accounting records?
1681 Accounting records are text lines containing tab-separated fields. The
1682 first 6 fields are always the same. These are:
1684 timestamp, NAS name, username, port, address, record type.
1686 Following these, a variable number of fields are written, depending on
1687 the accounting record type. All are of the form attribute=value. There
1688 will always be a task_id field.
1690 Current attributes are:
1708 "callback-dialstring"
1713 I expect more will be added over time.
1715 Example records are thus:
1717 Thu Jul 13 13:35:28 1995 cherub.cisco.com chein tty5 171.69.1.141 stop task_id=12028 service=exec port=5 elapsed_time=875
1718 Thu Jul 13 13:37:04 1995 cherub.cisco.com lol tty18 171.69.1.129 stop task_id=11613 service=exec port=18 service=exec port=18 elapsed_time=909
1719 Thu Jul 13 14:09:02 1995 cherub.cisco.com billw tty18 171.69.1.152 start task_id=17150 service=exec port=18
1720 Thu Jul 13 14:09:02 1995 cherub.cisco.com billw tty18 171.69.1.152 start task_id=17150 service=exec port=18 service=exec port=18
1723 Elapsed time is in seconds, and is the field most people are usually
1726 Q). How do I limit the number of sessions a user can have?
1728 A). The TACACS+ daemon can enforce how many simultaneous sessions a
1729 given user is allowed to have. You must compile the daemon with the
1730 MAXSESS symbol defined (see the Makefile).
1732 Maximum sessions are configured on the daemon for a user as follows:
1735 login = cleartext XXX
1737 # only allow two sessions max for joeslip
1740 name = "Joe SLIP User"
1744 It can also be configured under a group:
1746 group = slip_users {
1757 The daemon keeps a count of how many sessions a given user owns by
1758 monitoring START and STOP accounting records. Thus, exec and network
1759 accounting must be configured for this feature to operate for exec and
1762 As the restriction is enforced during the authorization phase of
1763 login, exec and network authorization must be configured as well, viz:
1765 aaa authentication login default tacacs+
1766 aaa authentication ppp default tacacs+
1767 aaa authorization exec tacacs+
1768 aaa authorization network tacacs+
1769 aaa accounting exec start-stop tacacs+
1770 aaa accounting network start-stop tacacs+
1772 Due to network outages (or other disruptions), it is possible for the
1773 TACACS+ daemon's record of usage to become out of sync with reality,
1774 so before denying access because it thinks a user is running too many
1775 sessions, the TACACS+ daemon will use the finger service on the NAS to
1776 verify how many sessions a user is running there.
1778 If the result of finger indicates that the daemon should permit
1779 access, access will be granted. Note that for this check to work via
1780 finger, "service finger" must also be configured on the NAS.
1782 Lastly, note that because finger output truncates usernames at 10
1783 characters, you may encounter trouble if you have users whose names
1784 are not unique within those first 10 characters.
1786 Also recall that authorization works differently on the console. So
1787 many people locked themselves out of their boxes after configuring
1788 authorization, that we stopped requiring authorization on the console
1789 for authenticated users. Since there's no authorization on the
1790 console, MAXSESS is not enforced there.
1792 Q). How can I configure time-outs on an interface via Tacacs+?
1794 A). Certain per-user/per-interface timeouts may be set by Tacacs+
1795 during authorization. As of 11.0, you can set an arap session timeout,
1796 and an exec timeout. As of 11.1 you can also set an exec idle timeout.
1798 There are currently no settable timeouts for PPP or SLIP sessions, but
1799 there is a workaround which applies to ASYNC PPP/SLIP idle timeouts
1800 started via exec sessions only: This workaround is to set an EXEC
1801 (idletime) timeout on an exec session which is later used to start up
1802 PPP or SLIP (either via a T+ autocommand or via the user explicitly
1803 invoking PPP or SLIP). In this case, the exec idle timeout will
1804 correctly terminate an idle PPP or SLIP session. Note that this
1805 workaround cannot be used for sessions which autoselect PPP or SLIP.
1807 An idle timeout terminates a connection when the interface is idle for
1808 a given period of time (this is equivalent to the "session-timeout"
1809 Cisco IOS configuration directive). The other timeouts are
1810 absolute. Of course, any timeouts set by Tacacs+ apply only to the
1815 login = cleartext foobar
1817 # disconnect lol if there is no traffic for 5 minutes
1819 # disconnect lol unconditionally after one hour
1823 You also need to configure exec authorization on the NAS for the above
1826 aaa authorization exec tacacs+
1828 Note that these timeouts only work for async lines, not for ISDN
1832 Note also that you cannot use the authorization "if-authenticated"
1833 option with these parameters, since that skips authorization if the
1834 user has successfully authenticated.
1836 Q). How do I send VPDN forwarding decisions to an authorization
1839 A). In 11.2 onwards, VPDN NASs can use T+ to allow an authorization
1840 server to make the decision to forward users.
1842 If VPDN forwarding is turned on, and the username is of the form
1843 user@domain, and "domain" matches a vpdn outgoing configured domain,
1844 then an authorization attempt is made for "domain" (see below).
1846 When making an authorization call for VPDN, a service type of "ppp"
1847 with a protocol type of "vpdn", with a username of "domain" will be
1848 made e.g. when a PPP user comes up on a line with the username
1849 foo@bar.com, if "vpdn enable" and "aaa authorization ...." is enabled
1850 on the box, then a one-time authorization of the name "bar.com" is
1853 If this authorization is successful, no local authentication is
1854 attempted on the NAS, and the connection is forwarded via VPDN
1857 If no VPDN-specific information comes back from this authorization
1858 call, the login proceeds as follows:
1860 If tacacs-server directed-requests are configured (note: this is true
1861 by default), then IOS will strip off the domain part of a name of the
1862 form user@domain and use "domain" to try and select a T+ server. If
1863 successful, the username portion "user", without the domain, will be
1864 used for all subsequent authentication, authorization and accounting.
1866 If directed requests are turned off, then the entire username
1867 user@domain is treated as a username.
1869 vpdn specific information includes the attributes "tunnel-id",
1870 "source-ip" (deprecated) and "ip-addresses":
1873 This AV pair specifies the username that will be used to
1874 authenticate the tunnel over which the individual user MID
1875 will be projected. This is analogous to the "NAS name" in the
1876 "vpdn outgoing" command.
1879 This is a list of possible IP addresses that can be used for
1880 the end-point of the tunnel. Consult the text at the end of
1881 this document for more details on how to configure this
1884 source-ip: (This is now deprecated. It began in release 11.2(1.4),
1885 and was removed in 11.2(4.0.2)).
1886 This ip address will be used as the source of all VPDN packets
1887 generated as part of the VPDN tunnel (see the source-ip
1888 keyword in the vpdn outgoing command).
1893 The following syntax is used on the public domain Tacacs+ server.
1896 service = ppp protocol = vpdn {
1897 tunnel-id = <name for tunnel authentication>
1898 ip-addresses = <addr> [<addr> ...]
1899 source-ip = <ip-address>
1903 In addition the T+ server can be used to store the usernames for both
1904 the NAS (the username specified by "tunnel-id" above) and the Home
1905 Gateway. These will be used to authenticate the tunnel.
1909 user = foobar.cisco.com {
1910 service = ppp protocol = vpdn {
1912 ip-addresses = "173.20.12.19 173.20.12.20"
1913 source-ip = 173.5.10.1
1918 global = cleartext egad
1921 user = my_home_gateway {
1922 global = cleartext wowser
1928 To enable AAA assisted VPDN forwarding on a NAS, the following minimum
1929 configuration is required:
1933 aaa authorization network tacacs+ ...
1935 In addition, if the passwords for the home gateway and NAS are stored
1936 on the T+ daemon, the command
1938 aaa authentication login tacacs+ ....
1940 should also be present.
1942 Beginning with release 11.2(1.4), the additional configuration
1944 vpdn outgoing cisco.com ip NAS [ source-ip X.X.X.X ]
1946 can be used. This changes in 11.2(4.0.2) and becomes:
1948 vpdn source-ip X.X.X.X
1949 vpdn outgoing cisco.com ip NAS
1952 Q). Can someone expand on the use of the "optional" keyword.
1954 A). Most attributes are mandatory i.e. if the daemon sends them to the
1955 NAS, the NAS must obey them or deny the authorization. This is the
1956 default. It is possible to mark attributes as optional, in which case
1957 a NAS which cannot support the attribute is free to simply ignore it
1958 without causing the authorization to fail.
1960 This was intended to be useful in cutover situations where you have
1961 multiple NASes running different versions of IOS, some of which
1962 support more attributes than others. If you make the new attributes
1963 optional, older NASes could ignore the optional attributes while new
1964 NASes could apply them. Note that this weakens your security a little,
1965 since you are no longer guaranteed that attributes are always applied
1966 on successful authorization, so it should be used judiciously.
1968 Q). Can I do do address pooling on the T+ daemon?
1970 A). Not really since nothing on the daemon tracks whether an address
1971 is already in use. The best way to do manage address pools is to
1972 define a non-overlapping pool of addresses on each NAS and return the
1973 name of this pool during authorization whenever a user logs in e.g.
1977 ip local pool foo 1.0.0.1 1.0.0.10
1982 service = ppp protocol = ip {
1988 Q). What about MSCHAP?
1990 A). Version F4.X contains mschap support. Mschap is configured the
1991 same way as chap, only using the "mschap" keyword in place of the
1994 Like ARAP, MSCHAP works best when you have a des library (see the note
1995 at the beginning of this document), but this is optional, as the DES
1996 calculation can be done by the NAS instead. It also optionally
1997 requires a key from Microsoft which is not public domain, but this can
1998 also be done on the NAS too, so you can live without it.
2000 To compile the daemon with MSCHAP support, uncomment the MSCHAP line
2001 in the Makefile. This will add the MSCHAP code to your daemon. You can
2002 leave MSCHAP_DES undefined, in which case the MSCHAP DES calculation
2003 will be done by NAS, and no special MSCHAP key will be required.
2005 If you have a DES library and want to use it with MSCHAP (this is more
2006 efficient for authentication), then you can also uncomment the
2007 MSCHAP_DES and MSCHAP_MD4_SRC lines in the Makefile. This will ensure
2008 that the DES calculation done in the daemon. A key will need to be
2009 obtained from Microsoft and used to replace the definition of
2010 MSCHAP_KEY in the file mschap.h. If you're thinking by now that this
2011 is all too much trouble, I can't say I blame you....
2013 Q). Can I do wtmp-style logging like xtacacd used to do?
2015 A). Wtmp file logging is supported. The "-u <wtmpfilename>" command
2016 line flag can be used to specify a filename which will be used for
2017 logging wtmp style records instead of the regular T+ accounting
2020 wtmp records are generated into wtmpfilename. Since file locking is
2021 also used when writing to wtmpfilename, the usual provisos regarding
2022 NFS and locking (see accounting above) should be observed.
2024 To generate correct wtmp log records, the NAS needs to be configured
2027 aaa accounting exec stop-only tacacs+
2028 aaa accounting network stop-only tacacs+
2029 aaa accounting system start-stop tacacs+
2031 CANNED CONFIGURATIONS
2032 ---------------------
2034 Here are some canned configurations for getting demos started:
2036 1). A canned configuration for login authentication only. This allows
2037 user fred to login with password "abcdef". If the tacacs+ server dies,
2038 the enable secret will be accepted as a login password instead.
2044 # repeat as necessary for each user
2046 login = cleartext abcdef
2052 enable secret foobar
2053 ! use tacacs+. If server dies, use the enable secret password
2054 aaa authentication login default tacacs+ enable
2055 tacacs-server host <some host ip address>
2056 tacacs-server key <some key>
2058 2). A canned configuration for command authorization. This will allow
2059 user fred to login with password abcdef and to run the privileged
2060 (level 15) commands 'write terminal' and 'configure'. All other
2061 privileged commands will be denied.
2063 The "none" keyword in the NAS configuration line means that if the
2064 tacacs+ server dies, any command will be allowed.
2070 # repeat as necessary for each user
2072 login = cleartext abcdef
2085 ! all level 15 (privileged commands). If server dies, allow everything
2086 aaa authorization commands 15 tacacs+ none
2087 tacacs-server host <some host ip address>
2088 tacacs-server key <some key>
2090 3). Canned configuration for network access authorization. This config
2091 allows "fred" to login to line 1 with password abcdef (or to and to
2092 run ppp using chap authentication. The chap password is "lab".
2098 # repeat as necessary for each user
2100 login = cleartext abcdef
2101 chap = cleartext lab
2102 service = ppp protocol = ip {
2110 ! authenticate exec logins (if not autoselecting)
2111 aaa authentication login default tacacs+
2112 ! authorize network services via tacacs+
2113 aaa authorization network tacacs+
2114 ! use tacacs+ for authenticating ppp users
2115 aaa authentication ppp default tacacs+
2116 tacacs-server host <some host ip address>
2117 tacacs-server key <some key>
2119 ip address 1.0.0.1 255.0.0.0
2120 async default ip address 172.21.14.55
2122 async dynamic address
2123 async mode interactive
2124 ! use chap to authenticate ppp users
2125 ppp authentication chap
2127 ! need "modem inout" here and flow control if using a modem
2129 4). Canned configuration for ARAP.
2134 aaa authentication arap default guest tacacs+
2135 aaa authorization network tacacs+
2136 aaa accounting network start-stop tacacs+
2139 arap network <number> <name>
2142 appletalk cable-range <range>
2143 appletalk zone <zonename>
2145 tacacs-server host <host>
2146 tacacs-server key <key>
2150 modem answer-timeout 0
2153 autoselect during-login
2156 flowcontrol hardware
2163 arap = cleartext <arap secret>
2167 Authorization AV pairs
2168 ----------------------
2169 The following authorization AV pairs are supported by 10.3(3) onwards
2170 except where specifically noted.
2172 The following AV pairs specify which service is being authorized. They
2173 are typically accompanied by protocol AV pairs and other, additional
2174 pairs from the lists below.
2177 service=shell (for exec startup, and also for command authorizations)
2181 service=system (not used).
2184 Used for managing reverse telnet connections e.g.
2187 login = cleartext lab
2189 port#1 = nasname1/tty2
2190 port#2 = nasname2/tty5
2194 Requires IOS configuration
2196 aaa authorization reverse-access tacacs+
2198 See the IOS docs for more details.
2201 The lower layer of PPP, always brought up before IP, IPX, etc.
2205 Used with service=ppp and service=slip to indicate which
2206 protocol layer is being authorized.
2210 Used with service=ppp to indicate which protocol layer
2211 is being authorized.
2214 with service=ppp or service=arap
2220 Authorization of CCP. Compression Control Protocol). No other
2221 av-pairs associated with this.
2224 Authorization of CDP (Cisco Discovery Protocol). No other
2225 av-pairs associated with this.
2228 Authorization of multilink PPP. See 'max-links' and 'load-threshold'.
2231 For undefined/unsupported conditions. Should not occur under
2232 normal circumstances.
2235 If the value of cmd is NULL e.g. the AV pair is cmd=, then
2236 this is an authorization request for starting an exec.
2238 If cmd is non-null, this is a command authorization request,
2239 It contains the name of the command being authorized
2243 During command authorization, the name of the command is given
2244 by an accompanying "cmd=" AV pair, and each command argument
2245 is represented by a cmd-arg AV pair e.g. cmd-arg=archie.sura.net
2247 NOTE: 'cmd-arg' should never appear in a configuration file.
2248 It is used internally by the daemon to construct a string
2249 which is then matched against the regular expressions which appear
2250 in a cmd clause in the configuration file.
2253 For ARAP this contains an access-list number. For EXEC
2254 authorization it contains an access-class number, e.g. acl=2.
2255 which is applied to the line as the output access class equivalent
2256 to the configuration command
2261 An outbound access-class is the best way to restrict outgoing telnet
2262 connections. Note that a suitable access list (in this case,
2263 numbered 2) must be predefined on the NAS.
2266 This AV pair contains an IP or IPX input access list number
2267 for slip or PPP e.g. inacl=2. The access list itself must be
2268 pre-configured on the Cisco box. Per-user access lists do not
2269 work with ISDN interfaces unless you also configure a virtual
2270 interface. After 11.2(5.1)F, you can also use the name of a
2271 predefined named access list, instead of a number, for the
2272 value of this attribute.
2274 Note: For IPX, inacl is only valid after 11.2(4)F.
2276 inacl#<n> (PPP/IP, PPP/IPX, 11.2(4)F)
2277 This AV pair contains the definition of an input access list
2278 to be installed and applied to an interface for the duration
2279 of the current connection, e.g.
2281 inacl#1="permit ip any any precedence immediate"
2282 inacl#2="deny igrp 0.0.1.2 255.255.0.0 any"
2284 Attributes are sorted numerically before they are applied.
2285 For IP, standard OR extended access list syntax may be used,
2286 but it is an error to mix the two within a given access-list.
2288 For IPX, only extended access list syntax may be used.
2293 sho ipx access-lists
2298 outacl (PPP/IP, PPP/IPX)
2299 This AV pair contains an IP or IPX output access list number
2300 for SLIP. PPP/IP or PPP/IPX connections e.g. outacl=4. The
2301 access list itself must be pre-configured on the Cisco
2302 box. Per-user access lists do not work with ISDN interfaces
2303 unless you also configure a virtual interface. PPP/IPX is
2304 supported in 11.1 onwards only. After 11.2(5.1)F, you can also
2305 use the name of a predefined named access list, as well as a
2306 number, for the value of this attribute.
2309 outacl#<n> (PPP/IP, PPP/IPX, 11.2(4)F)
2310 This AV pair contains an output access list definition to be
2311 installed and applied to an interface for the duration of the
2312 current connection, e.g.
2314 outacl#1="permit ip any any precedence immediate"
2315 outacl#2="deny igrp 0.0.9.10 255.255.0.0 any"
2317 Attributes are sorted numerically before they are applied.
2318 For IP, standard OR extended access list syntax may be used,
2319 but it is an error to mix the two within a given access-list.
2321 For IPX, only extended access list syntax may be used.
2326 sho ipx access-lists
2332 The IP address the remote host should be assigned when a slip
2333 or PPP/IP connection is made e.g. addr=1.2.3.4
2335 routing (SLIP, PPP/IP)
2336 Equivalent to the /routing flag in slip and ppp commands. Can
2337 have as its value the string "true" or "false".
2339 timeout (11.0 onwards, ARAP, EXEC)
2340 Sets the time until an arap or exec session disconnects
2341 unconditionally (in minutes), e.g. timeout=60
2344 During exec startup, this specifies an autocommand, like the
2345 autocommand option to the username configuration command,
2346 e.g. autocmd="telnet foo.com"
2349 During exec startup, this specifies "noescape", like the
2350 noescape option to the username configuration command. Can
2351 have as its value the string "true" or "false",
2355 During exec startup, this specifies "nohangup", like the
2356 nohangup option to the username configuration command. Can
2357 have as its value the string "true" or "false",
2361 Specifies the current privilege level for command
2362 authorizations, a number from zero to 15 e.g. priv_lvl=5.
2364 Note: in 10.3 this attribute was priv_lvl i.e.
2365 it contained an underscore instead of a hyphen.
2368 An Appletalk zonelist for arap equivalent to the line
2369 configuration command "arap zonelist" e.g. zonelist=5
2371 addr-pool (11.0 onwards, PPP/IP, SLIP)
2372 This AV pair specifies the name of a local pool from which to
2373 get the IP address of the remote host.
2375 Note: addr-pool works in conjunction with local pooling. It
2376 specifies the name of a local pool (which needs to be
2377 pre-configured on the NAS). Use the ip-local pool command to
2378 declare local pools, e.g on the NAS:
2380 ip address-pool local
2381 ip local pool foo 1.0.0.1 1.0.0.10
2382 ip local pool baz 2.0.0.1 2.0.0.20
2384 then you can use Tacacs+ to return addr-pool=foo or
2385 addr-pool=baz to indicate which address pool you want to get
2386 this remote node's address from, e.g. on the daemon:
2389 service = ppp protocol = ip {
2394 route (11.1 onwards, PPP/IP, SLIP).
2395 This AV pair specifies a route to be applied to an interface.
2397 During network authorization, the "route" attribute may be
2398 used to specify a per-user static route, to be installed via
2401 The daemon side declaration is:
2403 service=ppp protocol=ip {
2404 route="<dst_addr> <mask> [ <gateway> ]"
2407 This indicates a temporary static route that is to be
2408 applied. "<dst_address>, <mask> and [<gateway>]" are expected
2409 to be in the usual dotted-decimal notation, with meanings the
2410 same as for the familiar "ip route" configuration command on a
2413 If gateway is omitted, the peer's address is taken to be the gateway.
2415 The route is expunged once the connection terminates.
2417 route#<n> (PPP/IP/IPX, 11.2(4)F)
2418 Same as the "route" attribute, except that these are valid for
2419 IPX as well as IP, and they are numbered, allowing multiple
2420 routes to be applied e.g.
2422 route#1="3.0.0.0 255.0.0.0 1.2.3.4"
2423 route#2="4.0.0.0 255.0.0.0"
2428 route#1="4C000000 ff000000 30.12.3.4"
2429 route#2="5C000000 ff000000 30.12.3.5"
2437 callback-rotary (11.1 onwards, valid for ARAP, EXEC, SLIP or PPP)
2438 The number of a rotary group (between 0 and 100 inclusive)
2439 to use for callback e.g. callback-rotary=34. Not valid for ISDN.
2441 callback-dialstring (11.1 onwards, valid for ARAP, EXEC, SLIP or PPP)
2442 sets the telephone number for a callback e.g.
2443 callback-dialstring=408-555-1212. Not valid for ISDN.
2445 callback-line (11.1 onwards, valid for ARAP, EXEC, SLIP or PPP)
2446 The number of a tty line to use for callback e.g.
2447 callback-line=4. Not valid for ISDN.
2449 nocallback-verify (11.1 onwards, valid for ARAP, EXEC)
2450 Indicates that no callback verification is required. The only
2451 valid value for this parameter is the digit one i.e.
2452 nocallback-verify=1. Not valid for ISDN.
2454 idletime (11.1 onwards, EXEC)
2455 Sets a value, in minutes, after which an IDLE session will be
2456 terminated. N.B. Does NOT work for PPP.
2458 tunnel-id (11.2 onwards, PPP/VPDN)
2459 This AV pair specifies the username that will be used to
2460 authenticate the tunnel over which the individual user MID
2461 will be projected. This is analogous to the "NAS name" in the
2462 "vpdn outgoing" command.
2464 ip-addresses (11.2 onwards, PPP/VPDN)
2465 This is a space separated list of possible IP addresses that
2466 can be used for the end-point of the tunnel.
2468 In 11.2(5.4)F, this attribute was extended as follows:
2470 1) comma (',') is also consider as a delimiter
2471 For example the avpair can now be written as
2473 ip-addresses = 172.21.9.26,172.21.9.15,172.21.9.4
2475 2) '/' is considered a priority delimiter. When you have a
2476 number of Home Gateway routers, it is desirable to consider some
2477 as the primary routers and some as backup routers.
2479 The '/' allow you to config the routers into priority groups,
2480 so that the NAS will try to forward the users to the high
2481 priority routers, before forwarding to the low priority one.
2483 For example in the following avpair:
2485 ip-addresses = "172.21.9.26 / 172.21.9.15 / 172.21.9.4"
2487 172.21.9.26 is considered to be priority 1
2488 172.21.9.15 is considered to be priority 2
2489 172.21.9.4 is considered to be priority 3
2491 The NAS will try to forward the users to 172.21.9.26, before
2492 trying 172.21.9.15. If the NAS can't forward users to
2493 172.21.9.26, it will try 172.21.9.15 next. If it fails with
2494 172.21.9.15, it will then try forwarding to 172.21.9.4.
2496 source-ip (PPP/VPDN, now deprecated, only existed in releases 11.2(1.4)
2497 thru 11.2(4.0.2)). This specifies a single ip address will be
2498 used as the source of all VPDN packets generated as part of
2499 the VPDN tunnel (see the equivalent source-ip keyword in the
2500 IOS vpdn outgoing command).
2502 nas-password (PPP/VPDN, 11.2(3.4)F, 11.2(4.0.2)F)
2503 During L2F tunnel authentication, nas-password specifies the password
2506 gw-password (PPP/VPDN, 11.2(3.4)F, 11.2(4.0.2)F)
2507 During L2F tunnel authentication, gw-password specifies the password
2508 for the home gateway.
2510 rte-ftr-in#<n> (PPP -- IP/IPX, 11.2(4)F)
2511 This AV pair specifies an input access list definition to be
2512 installed and applied to routing updates on the current
2513 interface, for the duration of the current connection.
2515 For IP, both standard and extended Cisco access list syntax is
2516 recognised, but it is an error to mix the two within a given
2519 For IPX, only Cisco extended access list syntax is legal.
2521 Attributes are sorted numerically before being applied. For
2522 IP, the first attribute must contain the name of a routing
2523 process and its identifier (except for rip, where no
2524 identifier is needed), e.g.
2526 rte-fltr-in#0="router igrp 60"
2527 rte-fltr-in#1="permit 0.0.3.4 255.255.0.0"
2528 rte-fltr-in#2="deny any"
2530 For IPX, no routing process is needed, e.g.
2532 rte-fltr-in#1="deny 3C01.0000.0000.0001"
2533 rte-fltr-in#2="deny 4C01.0000.0000.0002"
2537 show ip access-lists
2539 sho ipx access-lists
2544 Related IOS commands:
2546 router <routing process identifier>
2547 [no] distribute-list <list-name> in <interface>
2550 ipx input-network-filter <access-list-number>
2553 rte-ftr-out#<n> (PPP/IP, 11.2(4)F)
2554 This AV pair specifies an input access list definition to be
2555 installed and applied to routing updates on the current
2556 interface, for the duration of the current connection.
2558 For IP, both standard and extended Cisco access list syntax is
2559 recognised, but it is an error to mix the two within a given
2562 Attributes are sorted numerically before being applied. The
2563 first attribute must contain the name of a routing process and
2564 its identifier (except for rip, where no identifier is
2567 rte-fltr-out#0="router igrp 60"
2568 rte-fltr-out#3="permit 0.0.5.6 255.255.0.0"
2569 rte-fltr-out#4="permit any"
2571 For IPX, no routing process is specified, e.g.
2573 rte-fltr-out#1="deny 3C01.0000.0000.0001"
2574 rte-fltr-out#2="deny 4C01.0000.0000.0002"
2578 sho ipx access-lists
2580 show ip access-lists
2585 Related IOS commands:
2587 router <routing process identifier>
2588 [no] distribute-list <list-name> in <interface>
2591 ipx output-network-filter <access-list-number>
2594 sap#<n> (11.2(4)F PPP/IPX)
2595 This AV pair specifies static saps to be installed for the duration
2596 of a connection e.g.
2598 sap#1="4 CE1-LAB 1234.0000.0000.0001 451 4"
2599 sap#2="5 CE3-LAB 2345.0000.0000.0001 452 5"
2601 The syntax of static saps is the same as that used by the IOS
2609 Related IOS commands:
2613 route#<n> (PPP/IP/IPX, 11.2(4)F)
2615 Same as the "route" attribute, except that these are valid for
2616 IPX as well as IP, and they are numbered, allowing multiple
2617 routes to be applied e.g.
2619 route#1="3.0.0.0 255.0.0.0 1.2.3.4"
2620 route#2="4.0.0.0 255.0.0.0"
2625 route#1="4C000000 ff000000 30.12.3.4"
2626 route#2="5C000000 ff000000 30.12.3.5"
2635 sap-fltr-in#<n> (PPP/IPX, 11.2(4)F)
2636 This AV pair specifies an input sap filter access list
2637 definition to be installed and applied on the current
2638 interface, for the duration of the current connection.
2640 Only Cisco extended access list syntax is legal, e.g
2642 sap-fltr-in#1="deny 6C01.0000.0000.0001"
2643 sap-fltr-in#2="permit -1"
2645 Attributes are sorted numerically before being applied.
2647 sho ipx access-lists
2652 [no] ipx input-sap-filter <number>
2655 sap-fltr-out#<n> (PPP/IPX 11.2(4)F)
2656 This AV pair specifies an output sap filter access list
2657 definition to be installed and applied on the current
2658 interface, for the duration of the current connection.
2660 Only Cisco extended access list syntax is legal, e.g
2662 sap-fltr-out#1="deny 6C01.0000.0000.0001"
2663 sap-fltr-out#2="permit -1"
2665 Attributes are sorted numerically before being applied.
2667 sho ipx access-lists
2672 [no] ipx output-sap-filter <number>
2676 pool-def#<n> (PPP/IP, 11.2(4)F)
2677 This attribute is used to define ip address pools on the NAS.
2679 During IPCP address negotiation, if an ip pool name is
2680 specified for a user (see the addr-pool attribute), a check is
2681 made to see if the named pool is defined on the NAS. If it is,
2682 the pool is consulted for an ip address.
2684 If the required pool is not present on the NAS (either in the
2685 local config, or as a result of a previous download
2686 operation), then an authorization call to obtain it is
2687 attempted, using the special username:
2691 where <nas-name> is the configured name of the NAS.
2693 Note: This username can be changed using the IOS configuration
2696 aaa configuration config-name nas1-pools-definition.cisco.us
2698 The pool-def attribute is used to define ip address pools for
2699 the above authorization call e.g.
2702 login = cleartext lab
2703 service = ppp protocol = ip {
2709 service = ppp protocol = ip {
2710 pool-def#1 = "aaa 1.0.0.1 1.0.0.3"
2711 pool-def#2 = "bbb 2.0.0.1 2.0.0.10"
2712 pool-def#3 = "ccc 3.0.0.1 3.0.0.20"
2718 In the example above is a configuration file fragment for defining 3
2719 pools named "aaa", "bbb" and "ccc" on the NAS named "nas1".
2721 When the user "foo" refers to the pool named "bbb", if the
2722 pool "bbb" isn't defined, the NAS will attempt to download the
2723 definition contained in the "nas1-pools" entry.
2725 The other pools will also be defined at the same time (or they
2726 will be ignored if they are already defined).
2728 Since this procedure is only activated when an undefined pool
2729 is referenced, one way to redefine a pool once it has been
2730 downloaded is to manually delete the definition e.g. by
2731 logging into the NAS, enabling, and configuring:
2734 no ip local pool bbb
2737 When a pool is deleted, there is no interruption in service
2738 for any user who is currently using a pool address. If a pool
2739 is deleted and then subsequently redefined to include a pool
2740 address that was previously allocated, the new pool will pick
2741 up the allocated address and track it as expected.
2743 Since downloaded pools do not appear in the NAS configuration,
2744 any downloaded pool definitions automatically disappear
2745 whenever a NAS reboots. These pools are marked as "dynamic"
2746 when they appear in the output of the "show ip local pools"
2749 Since it is desirable not to have to manually delete pools to
2750 redefine them, the AV pair pool-timeout=<n> can be used to
2751 timeout any downloaded pool definitions. The timeout <n> is in
2754 The effect of the pool-timeout attribute is to start a timer
2755 when the pool definitions are downloaded. When the timer
2756 expires, the pools are deleted. The next reference to a
2757 deleted pool via will cause a re-fetch of the pool
2758 definitions. This allows pool changes to be made on the
2759 daemon and propagated to the NAS in a timely manner.
2764 sho ip local pool <pool-name>
2768 ip local pool <name> <start address> <end address>
2771 old-prompts (PPP/SLIP)
2772 This attribute is integrated into the following IOS images:
2774 11.2(7.4)P 11.2(7.4) 11.1(13.1) 11.(16.2) 11.1(13.1)AA
2775 11.1(13.1)CA 11.1(13.1)IA 11.2(8.0.1)F 11.0(16.2)BT)
2777 This attribute allows providers to make the prompts in T+
2778 appear identical to those of earlier systems (tacacs and
2779 xtacacs). This will allow administrators to upgrade from
2780 tacacs/xtacacs to T+ transparently to users.
2782 The difference between the prompts is as follows:
2784 In xtacacs, when the user types "slip" or "ppp" the system
2785 prompts for an address followed by a password, whereas T+
2786 prompts only for an address.
2788 In xtacacs, if the user types "slip host" or "ppp host", the
2789 system prompts for a password. In T+, there is no prompt.
2791 Using this attribute, T+ can be made to mimic the prompting
2792 behaviour of xtacacs, by configuring network authorization on
2793 IOS, and using the "old-prompts=true" attribute value pair for
2794 slip and ppp/ip, viz:
2797 global = cleartext foo
2802 default attribute = permit
2805 service = ppp protocol = ip {
2806 default attribute = permit
2811 i.e. the prompts are controlled by the addition of the
2812 "old-prompts=true" attribute.
2815 max-links (PPP/multilink - Multilink parameter; 11.3)
2816 This AV pair restricts the number of multilink bundle links
2817 that a user can have.
2819 The daemon side declaration is:
2821 service=ppp protocol=multilink {
2825 The range of <n> is [1-255].
2827 Related NAS commands:
2830 int virtual-template X
2831 multilink max-links <n>
2836 load-threshold (PPP/multilink - Multilink parameter; 11.3)
2837 This AV pair sets the load threshold at which an additional
2838 multilink link is added to the bundle (if load goes above) or
2839 deleted (if load goes below).
2841 The daemon side declaration is:
2843 service=ppp protocol=multilink {
2847 The range of <n> is [1-255].
2849 Related NAS commands:
2852 int virtual-template X
2853 multilink load-threshold <n>
2859 Reserved for future use:
2861 ppp-vj-slot-compression
2864 x25-addresses (PPP/VPDN)
2865 frame-relay (PPP/VPDN)