home *** CD-ROM | disk | FTP | other *** search
/ ftp.shrubbery.net / 2015-02-07.ftp.shrubbery.net.tar / ftp.shrubbery.net / pub / tac_plus / tacacs+-F4.0.4.27a.tar.gz / tacacs+-F4.0.4.27a.tar / tacacs+-F4.0.4.27a / FAQ < prev    next >
Text File  |  2012-03-21  |  26KB  |  638 lines
  1. FREQUENTLY ASKED QUESTIONS
  2. --------------------------
  3. Q). Can the daemon authenticate against LDAP, SecurID, and similar?
  4. A). PAM is the best manner of integrating LDAP, SecurID, and similar with
  5.     Tacacs.  Tacacs then uses PAM to resolve authentication requests and
  6.     PAM in-turn makes queries to/through the given service.
  7.  
  8.     Some PAM configuration is necessary.  There are at least three different
  9.     PAM configuration methods; no attempt to guide your configuration has
  10.     been made by us.
  11.  
  12.     To use PAM, the daemon must have been built with PAM support.  The
  13.     configure script attempts to location the PAM libraries by default and
  14.     will include PAM support if they're found.  Otherwise, you have to figure
  15.     out why its not finding them.
  16.  
  17.     On Linux, the pam-dev library packages are needed.
  18.  
  19. Q). Does tac_plus required a working DNS?
  20. A). As distributed, whenever a START packet arrive, the daemon makes a
  21.     call to getpeername to find out the name of the requestor. Depending
  22.     entirely on how your Unix host is set up, this may make DNS
  23.     queries. If this is a problem, comment out the code in tac_plus.c
  24.     which does this, and just use ip addresses instead of host names.
  25.  
  26. Q). Is the "name" field used for anything
  27. A). No. It's purely for documentation. I had once thought it might be
  28.     useful when outputting error messages, and that you might need the
  29.     information if you converted a passwd(5) style file, but no use is
  30.     currently made of the field.
  31.  
  32. Q). Why do I get PPP authorization failures because of "no username in
  33.     request" when I've already logged in and authenticated?
  34. A). With "aaa authentication PPP default tacacs+", the ppp
  35.     authentication overrides the earlier login authentication.  If the ppp
  36.     authentication fails, the username ends up blank.  Changing the config
  37.     to "aaa authentication ppp default if-needed tacacs+" fixes this
  38.     problem.
  39.  
  40. Q). I'm sure I configured it correctly, but accounting still doesn't
  41.     work.
  42. A). You will find that although you can configure accounting in 10.3,
  43.     and it outputs debug messages, it doesn't send any accounting
  44.     packets. This is because Accounting only works from 11.0 onwards.
  45.  
  46. Q). Does TACACS+ use a database instead of a flat (/etc/passwd like)
  47.     file to decrease search times, say if we are talking about a large
  48.     database of 40,000 users?
  49. A). The TACACS+ authentication database is held internally as a hash
  50.     table. This makes lookup times fast and fairly linear, at the expense
  51.     of making the server use potentially large amounts of memory space.
  52.     NOTE: If you specify that the server uses passwd(5) files for
  53.     authentication, then you don't get this speed benefit, but you save
  54.     space.
  55.  
  56.     If you're willing to write the code, it should be a relatively simple
  57.     matter to interface the code to a database scheme e.g. unix dbm files,
  58.     or some proprietary database package, if you wish.
  59.  
  60. Q). Is there any way to avoid having clear text versions of the
  61.     ARAP and CHAP secrets in the configuration file?
  62.  
  63. A). CHAP and ARAP require that the server knows the cleartext password (or
  64.     equivalently, something from which the server can generate the
  65.     cleartext password). Note that this is part of the definition of CHAP
  66.     and ARAP, not just the whim of some Cisco engineer who drank too much
  67.     coffee late one night.
  68.  
  69.     If we encrypted the CHAP and ARAP passwords in the database, then we'd
  70.     need to keep a key around so that the server can decrypt them when
  71.     CHAP or ARAP needs them.  So this only ends up being a slight
  72.     obfuscation and not much more secure than the original scheme.
  73.  
  74.     In extended TACACS, the CHAP and ARAP secrets were separated from the
  75.     password file because the password file may be a system password file
  76.     and hence world readable.  But with TACACS+'s native database, there
  77.     is no such requirement, so we think the best solution is to
  78.     read-protect the files.  Note that this is the same problem that a
  79.     kerberos server has.  If your security is compromised on the kerberos
  80.     server, then your database is wide open.  Kerberos does encrypt the
  81.     database, but if you want your server to automatically restart, then
  82.     you end up having to "kstash" the key in a file anyway and you're back
  83.     to the same security problem.
  84.  
  85.     So storing the cleartext password on the security server is really an
  86.     absolute requirement of the CHAP and ARAP protocols, not something
  87.     imposed by TACACS+.
  88.  
  89.     We could have chosen a scheme where the NAS sends the challenge
  90.     information to the TACACS+ daemon and the daemon uses the cleartext
  91.     password to generate the response and returns that, but that means
  92.     that we must include specific protocol knowledge into the protocol for
  93.     both ARAP and CHAP and we would have to update the protocol every time
  94.     a new authentication protocol is added.  Hence we decided to go with
  95.     the SENDPASS mechanism.
  96.  
  97.     Note that the above doesn't apply to PAP. You can keep an inbound PAP
  98.     password des-encrypted, since all you need to do with it is verify
  99.     that the password the principal gave you is correct.
  100.  
  101. Q). How is the typical login authentication sequence done?
  102. A). NAS sends START packet to daemon
  103.     Daemon send GETUSER containing login prompt to NAS
  104.     NAS prompts user for username
  105.     NAS sends pkt to daemon
  106.     Daemon sends GETPASS containing password prompt to the NAS
  107.     NAS prompts user for password
  108.     NAS sends pkt to daemon
  109.     Daemon sends accept, reject or error to NAS
  110.  
  111.  
  112. Q). Is there a GUI for the configuration file?
  113. A). No. Use your favourite text editor.
  114.  
  115.  
  116. Q). What does "default service = permit" really do?
  117. A). When a request comes in to authorize exec startup, or ppp (with
  118.     protocol lcp, ip, ipx), or slip, or arap or a specific command, the
  119.     daemon looks for a matching declarations for the user (or groups the
  120.     user is a member of).
  121.  
  122.     For exec startup, it looks for a "service=exec" OR any command
  123.     configured.
  124.  
  125.     For ppp, it looks for a "service=ppp" and "protocol=(one of lcp, ip, ipx)".
  126.  
  127.     For slip there must be a "service=slip" and for arap a "service=arap"
  128.     clause.
  129.  
  130.     For specific commands, there must be a matching cmd=<cmdname>.
  131.  
  132.     If these aren't found, authorization will fail, *unless* you say
  133.     "default service = permit".
  134.  
  135. Q). How do I make PAP work?
  136. A). Avoid using PAP if possible since it's not very secure. If you
  137.     *must* use it, PAP passwords may be specified along with arap and chap
  138.     passwords for each user. Note that the details of this changed in
  139.     version 3.0 and onwards.
  140.  
  141.     For outbound PAP, where you are forced to send a password to the
  142.     remote host to identify yourself, there is now a separate "opap"
  143.     directive e.g.
  144.  
  145.     opap = cleartext OOOO
  146.  
  147.     You use this to set the outbound PAP password. It must be a cleartext
  148.     password.
  149.  
  150.     NOTE: It is very bad practice to use an outbound PAP password that is
  151.     the same as any of your inbound passwords. For this reason, a "global"
  152.     password does not apply to outbound PAP, only to inbound PAP,
  153.     bidirectional CHAP and ARAP.
  154.  
  155.     Before 3.0, PAP logins were treated like ordinary user logins, so you
  156.     needed to declare a user in the Daemon configuration file whose name
  157.     was typically the remote hostname (or user), with a login password, in
  158.     order to process the PAP request.
  159.  
  160. Q). How can I deny some one from telneting from a commserver by ip
  161.     address only. i.e. when command is 10.0.1.6 rather than telnet
  162.     10.0.1.6.
  163. A).  The best way to restrict telnet access is by applying an outbound
  164.     access list via the access class command (or equivalently, via the
  165.     "acl" avpair). The NAS configuration command "access-class <n> out"
  166.     for example applies a pre-defined standard IP access list (where n is
  167.     a number from 1 through 99) that governs telnet access from a NAS.
  168.  
  169.     E.g. the following configuration commands permit outgoing Telnet
  170.     access from line 1 on the NAS *only* to hosts on network 192.85.55.0:
  171.  
  172.     access-list 12 permit 192.85.55.0 0.0.0.255
  173.     line 1
  174.     access-class 12 out
  175.  
  176.     Note: you must define "access-list 12 permit 192.85.55.0 0.0.0.255" on
  177.     the NAS. Only then can you use the acl avpair to apply it to a line
  178.     that a user dials in on.
  179.  
  180.     Alternatively, you can try configuring "transport preferred none" on
  181.     the lines in question. This will force a user to always type "telnet
  182.     10.0.1.6" in order to telnet out from the NAS.  Then you can apply
  183.     command authorization to this command to restrict it.
  184.  
  185. Q). I have an autocommand configured in the NAS-local database and I'm
  186.     using "aaa authentication local-override". The autocommand doesn't
  187.     work, but the username/password does. Why?
  188. A). The "local-override" only applies to the authentication portion of
  189.     the local database, so if you want an autocommand for this user, you
  190.     need to also do:
  191.  
  192.     aaa authorization exec local if-authenticated
  193.  
  194.     This will use the local DB entry if one exists, allow authenticated
  195.     users otherwise, or fail.
  196.  
  197.     We don't have a "aaa authorization local-override" like we do for
  198.     authentication. Unlike authentication, the local method for
  199.     authorization is sort of equivalent to a local-override.
  200.  
  201. Q). Can tacacs+ only be enabled on a global basis? I want to
  202.     selectively turn it on for, e.g. only modem-connected lines. How do I
  203.     do this?
  204. A). You turn tacacs+ ON on a global basis, but you can then change the
  205.     behavior of individual lines to whatever you want, e.g.
  206.  
  207.         aaa authentication login default tacacs+ none
  208.         aaa authentication login oldstyle line
  209.         aaa authentication login none none
  210.         line 1 16
  211.         login authentication default
  212.         line vty 0 4
  213.         login authentication oldstyle
  214.         line 0
  215.         login authentication none
  216.  
  217.     Note that unfortunately, you can't (yet) apply authorization
  218.     differently to selected lines and interfaces.
  219.  
  220. Q). I have leased lines running PPP, and AAA authorization is also
  221.     configured, so the authorization on the leased lines fails.  What should
  222.     I do?
  223. A). Since you can't (yet) configure authorization on a per-line basis,
  224.     you have to turn on authentication on the leased lines running PPP and
  225.     configure your T+ server so that it will authorize these lines
  226.     correctly.
  227.  
  228.     A more demanding alternative is to modify the TACACS+ server source code
  229.     to allow any authorizations coming in from the port "SerialXXX" to
  230.     succeed.
  231.  
  232.     A third possibility is to not use PPP on those lines, e.g. use HDLC
  233.     instead. HDLC doesn't require authentication or authorization.
  234.  
  235. Q). What are the memory recommendations for TACACS+?
  236. A). Unless you're using passwd style files, TACACS+ holds entries in
  237.     hash tables in memory. The overhead is modest e.g. each user entry
  238.     occupies 72 bytes, plus space for strings like username and password
  239.     etc. Access time should thus be pretty constant regardless of number
  240.     of users. On a sparc 2, a config file containing 2000 users requires
  241.     about 0.5M of swap.
  242.  
  243. Q). How many users will a TACACS+ server support?  What happens when
  244.     the maximum is exceeded?
  245.  
  246.     There are 2 issues. The first is that each entry in the config file
  247.     occupies memory (swap space) so you could run out of swap space either
  248.     starting up the daemon or when it forks to answer incoming requests
  249.     (see above). If this happens, the daemon will drop the connection
  250.     which should appear as an error to the NAS) and the logfile will
  251.     contain appropriate error messages. The solution is usually to add
  252.     more disk space for swapping.
  253.  
  254.     The second issue is speed: Using config files containing 75,000 user
  255.     entries, I'm seeing about 3 authentications per second on a sparc 2
  256.     without noticeable performance impact, though I haven't benchmarked
  257.     this formally.
  258.  
  259.     So more than about 3 authentications per second on this platform will
  260.     result in users seeing delays and having to wait for prompts.  The
  261.     usual solution to this is to add more daemons to spread the load out.
  262.  
  263. Q). How many characters may a TACACS+ Username and Password contain?
  264. A). The short answer is 31 bytes of username, with up to 254 bytes of
  265.     password if they are cleartext (8 bytes if passwords are des encrypted).
  266.  
  267.     The long answer is that the Cisco NAS allocates a buffer of 1024
  268.     bytes, so this is the maximum you can type in, in response to a NAS
  269.     prompt.
  270.  
  271.     But the protocol spec allows a username or password length field of
  272.     just one byte in an authentication packet, so only the first 255 of
  273.     these characters can be sent to the daemon.
  274.  
  275.     Then, the API spec states that the username in the identity structure
  276.     on the daemon is 32 bytes long, so only the first 31 bytes of username
  277.     will be copied from the authentication packet into this structure,
  278.     which is then null-terminated.
  279.  
  280.     The password, on the other hand, is copied into malloc'ed memory, so
  281.     it can still be up to 255 characters long.
  282.  
  283.     Now if it's a des encrypted password, then only the first 8 bytes are
  284.     significant, per the common unix implementations of crypt.
  285.  
  286.     Lastly, there is also the question of how long a username/password can
  287.     be configured in the daemon configuration file. The answer is given by
  288.     the value of MAX_INPUT_LINE_LEN, currently set to 255, which
  289.     determines the length of the longest string you can enter in the
  290.     configuration file.
  291.  
  292. Q). What is the format of accounting records?
  293. A). Accounting records are text lines containing tab-separated fields. The
  294.     first 6 fields are always the same. These are:
  295.  
  296.     timestamp, NAS name, username, port, address, record type.
  297.  
  298.     Following these, a variable number of fields are written, depending on
  299.     the accounting record type. All are of the form attribute=value. There
  300.     will always be a task_id field.
  301.  
  302.     Current attributes are:
  303.  
  304.     "unknown"
  305.     "service"
  306.     "start_time"
  307.     "port"
  308.     "elapsed_time"
  309.     "status"
  310.     "priv_level"
  311.     "cmd"
  312.     "protocol"
  313.     "cmd-arg"
  314.     "bytes_in"
  315.     "bytes_out"
  316.     "paks_in"
  317.     "paks_out"
  318.     "address"
  319.     "task_id"
  320.     "callback-dialstring"
  321.     "nocallback-verify"
  322.     "callback-line"
  323.     "callback-rotary"
  324.  
  325.     I expect more will be added over time.
  326.  
  327.     Example records are thus:
  328.  
  329.     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
  330.     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
  331.     Thu Jul 13 14:09:02 1995    cherub.cisco.com    billw    tty18    171.69.1.152    start    task_id=17150    service=exec    port=18
  332.     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
  333.  
  334.     Elapsed time is in seconds, and is the field most people are usually
  335.     interested in.
  336.  
  337. Q). How do I limit the number of sessions a user can have?
  338. A). The TACACS+ daemon can enforce how many simultaneous sessions a
  339.     given user is allowed to have.  You must compile the daemon with the
  340.     MAXSESS symbol defined (see the Makefile).
  341.  
  342.     Maximum sessions are configured on the daemon for a user as follows:
  343.  
  344.     user = joeslip {
  345.     login = cleartext XXX
  346.  
  347.     # only allow two sessions max for joeslip
  348.     maxsess = 2
  349.  
  350.     name = "Joe SLIP User"
  351.     ...
  352.     }
  353.  
  354.     It can also be configured under a group:
  355.  
  356.     group = slip_users {
  357.     maxsess = 2
  358.     ...
  359.     }
  360.     ...
  361.     user = fred {
  362.     ...
  363.     member = slip_users
  364.     ...
  365.     }
  366.  
  367.     The daemon keeps a count of how many sessions a given user owns by
  368.     monitoring START and STOP accounting records.  Thus, exec and network
  369.     accounting must be configured for this feature to operate for exec and
  370.     ppp users.
  371.  
  372.     As the restriction is enforced during the authorization phase of
  373.     login, exec and network authorization must be configured as well, viz:
  374.  
  375.     aaa authentication login default tacacs+
  376.     aaa authentication ppp default tacacs+
  377.     aaa authorization exec tacacs+
  378.     aaa authorization network tacacs+
  379.     aaa accounting exec start-stop tacacs+
  380.     aaa accounting network start-stop tacacs+
  381.  
  382.     Due to network outages (or other disruptions), it is possible for the
  383.     TACACS+ daemon's record of usage to become out of sync with reality,
  384.     so before denying access because it thinks a user is running too many
  385.     sessions, the TACACS+ daemon will use the finger service on the NAS to
  386.     verify how many sessions a user is running there.
  387.  
  388.     If the result of finger indicates that the daemon should permit
  389.     access, access will be granted.  Note that for this check to work via
  390.     finger, "service finger" must also be configured on the NAS.
  391.  
  392.     Lastly, note that because finger output truncates usernames at 10
  393.     characters, you may encounter trouble if you have users whose names
  394.     are not unique within those first 10 characters.
  395.  
  396.     Also recall that authorization works differently on the console. So
  397.     many people locked themselves out of their boxes after configuring
  398.     authorization, that we stopped requiring authorization on the console
  399.     for authenticated users. Since there's no authorization on the
  400.     console, MAXSESS is not enforced there.
  401.  
  402. Q). How can I configure time-outs on an interface via Tacacs+?
  403. A). Certain per-user/per-interface timeouts may be set by Tacacs+
  404.     during authorization. As of 11.0, you can set an arap session timeout,
  405.     and an exec timeout. As of 11.1 you can also set an exec idle timeout.
  406.  
  407.     There are currently no settable timeouts for PPP or SLIP sessions, but
  408.     there is a workaround which applies to ASYNC PPP/SLIP idle timeouts
  409.     started via exec sessions only: This workaround is to set an EXEC
  410.     (idletime) timeout on an exec session which is later used to start up
  411.     PPP or SLIP (either via a T+ autocommand or via the user explicitly
  412.     invoking PPP or SLIP). In this case, the exec idle timeout will
  413.     correctly terminate an idle PPP or SLIP session. Note that this
  414.     workaround cannot be used for sessions which autoselect PPP or SLIP.
  415.  
  416.     An idle timeout terminates a connection when the interface is idle for
  417.     a given period of time (this is equivalent to the "session-timeout"
  418.     Cisco IOS configuration directive). The other timeouts are
  419.     absolute. Of course, any timeouts set by Tacacs+ apply only to the
  420.     current connection.
  421.  
  422.  
  423.     user = lol {
  424.     login = cleartext foobar
  425.     service = exec {
  426.         # disconnect lol if there is no traffic for 5 minutes
  427.         idletime = 5
  428.         # disconnect lol unconditionally after one hour
  429.             timeout = 60
  430.     }
  431.     }
  432.  
  433.     You also need to configure exec authorization on the NAS for the above
  434.     timeouts, e.g.
  435.  
  436.         aaa authorization exec tacacs+
  437.  
  438.     Note that these timeouts only work for async lines, not for ISDN currently.
  439.  
  440.  
  441.     Note also that you cannot use the authorization "if-authenticated"
  442.     option with these parameters, since that skips authorization if the
  443.     user has successfully authenticated.
  444.  
  445. Q). How do I send VPDN forwarding decisions to an authorization server?
  446. A). In 11.2 onwards, VPDN NASs can use T+ to allow an authorization
  447.     server to make the decision to forward users.
  448.  
  449.     If VPDN forwarding is turned on, and the username is of the form
  450.     user@domain, and "domain" matches a vpdn outgoing configured domain,
  451.     then an authorization attempt is made for "domain" (see below).
  452.  
  453.     When making an authorization call for VPDN, a service type of "ppp"
  454.     with a protocol type of "vpdn", with a username of "domain" will be
  455.     made e.g. when a PPP user comes up on a line with the username
  456.     foo@bar.com, if "vpdn enable" and "aaa authorization ...." is enabled
  457.     on the box, then a one-time authorization of the name "bar.com" is
  458.     attempted.
  459.  
  460.     If this authorization is successful, no local authentication is
  461.     attempted on the NAS, and the connection is forwarded via VPDN
  462.     instead.
  463.  
  464.     If no VPDN-specific information comes back from this authorization
  465.     call, the login proceeds as follows:
  466.  
  467.     If tacacs-server directed-requests are configured (note: this is true
  468.     by default), then IOS will strip off the domain part of a name of the
  469.     form user@domain and use "domain" to try and select a T+ server. If
  470.     successful, the username portion "user", without the domain, will be
  471.     used for all subsequent authentication, authorization and accounting.
  472.  
  473.     If directed requests are turned off, then the entire username
  474.     user@domain is treated as a username.
  475.  
  476.     vpdn specific information includes the attributes "tunnel-id",
  477.     "source-ip" (deprecated) and "ip-addresses":
  478.  
  479.     tunnel-id:
  480.     This AV pair specifies the username that will be used to
  481.     authenticate the tunnel over which the individual user MID
  482.     will be projected.  This is analogous to the "NAS name" in the
  483.     "vpdn outgoing" command.
  484.  
  485.     ip-addresses:
  486.     This is a list of possible IP addresses that can be used for
  487.     the end-point of the tunnel. Consult the text at the end of
  488.     this document for more details on how to configure this
  489.     attribute.
  490.  
  491.     source-ip: (This is now deprecated. It began in release 11.2(1.4),
  492.         and was removed in 11.2(4.0.2)).
  493.     This ip address will be used as the source of all VPDN packets
  494.     generated as part of the VPDN tunnel (see the source-ip
  495.     keyword in the vpdn outgoing command).
  496.  
  497.     Tacacs+ syntax
  498.     --------------
  499.  
  500.     The following syntax is used on the public domain Tacacs+ server.
  501.  
  502.     username = domain {
  503.     service = ppp protocol = vpdn {
  504.         tunnel-id = <name for tunnel authentication>
  505.         ip-addresses = <addr> [<addr> ...]
  506.         source-ip = <ip-address>
  507.     }
  508.     }
  509.  
  510.     In addition the T+ server can be used to store the usernames for both
  511.     the NAS (the username specified by "tunnel-id" above) and the Home
  512.     Gateway.  These will be used to authenticate the tunnel.
  513.  
  514.     Example:
  515.  
  516.     user = foobar.cisco.com {
  517.     service = ppp protocol = vpdn {
  518.         tunnel-id = my_nas
  519.         ip-addresses = "173.20.12.19 173.20.12.20"
  520.         source-ip = 173.5.10.1
  521.     }
  522.     }
  523.  
  524.     user = my_nas {
  525.     global = cleartext egad
  526.     }
  527.  
  528.     user = my_home_gateway {
  529.     global = cleartext wowser
  530.     }
  531.  
  532.     IOS Configuration
  533.     -----------------
  534.  
  535.     To enable AAA assisted VPDN forwarding on a NAS, the following minimum
  536.     configuration is required:
  537.  
  538.     vpdn enable
  539.     aaa new-model
  540.     aaa authorization network tacacs+ ...
  541.  
  542.     In addition, if the passwords for the home gateway and NAS are stored
  543.     on the T+ daemon, the command
  544.  
  545.     aaa authentication login tacacs+ ....
  546.  
  547.     should also be present.
  548.  
  549.     Beginning with release 11.2(1.4), the additional configuration
  550.  
  551.     vpdn outgoing cisco.com ip NAS [ source-ip X.X.X.X ]
  552.  
  553.     can be used. This changes in 11.2(4.0.2) and becomes:
  554.  
  555.     vpdn source-ip X.X.X.X
  556.     vpdn outgoing cisco.com ip NAS
  557.  
  558.  
  559. Q). Can someone expand on the use of the "optional" keyword.
  560. A). Most attributes are mandatory i.e. if the daemon sends them to the
  561.     NAS, the NAS must obey them or deny the authorization. This is the
  562.     default. It is possible to mark attributes as optional, in which case
  563.     a NAS which cannot support the attribute is free to simply ignore it
  564.     without causing the authorization to fail.
  565.  
  566.     This was intended to be useful in cutover situations where you have
  567.     multiple NASes running different versions of IOS, some of which
  568.     support more attributes than others. If you make the new attributes
  569.     optional, older NASes could ignore the optional attributes while new
  570.     NASes could apply them. Note that this weakens your security a little,
  571.     since you are no longer guaranteed that attributes are always applied
  572.     on successful authorization, so it should be used judiciously.
  573.  
  574. Q). Can I do do address pooling on the T+ daemon?
  575. A). Not really since nothing on the daemon tracks whether an address
  576.     is already in use. The best way to do manage address pools is to
  577.     define a non-overlapping pool of addresses on each NAS and return the
  578.     name of this pool during authorization whenever a user logs in e.g.
  579.  
  580.     NAS:
  581.  
  582.     ip local pool foo 1.0.0.1 1.0.0.10
  583.  
  584.     Daemon:
  585.  
  586.     user = lol {
  587.     service = ppp protocol = ip {
  588.         addr-pool = foo
  589.     }
  590.     }
  591.  
  592.  
  593. Q). What about MSCHAP?
  594. A). Version F4.X contains mschap support. Mschap is configured the
  595.     same way as chap, only using the "mschap" keyword in place of the
  596.     "chap" keyword.
  597.  
  598.     Like ARAP, MSCHAP works best when you have a des library (see the note
  599.     at the beginning of this document), but this is optional, as the DES
  600.     calculation can be done by the NAS instead. It also optionally
  601.     requires a key from Microsoft which is not public domain, but this can
  602.     also be done on the NAS too, so you can live without it.
  603.  
  604.     To compile the daemon with MSCHAP support, give configured the
  605.     --enable-mschap option.  This will add the MSCHAP code to your daemon.
  606.     You can leave MSCHAP_DES undefined (see configure --enable-mschapdes),
  607.     in which case the MSCHAP DES calculation will be done by NAS, and no
  608.     special MSCHAP key will be required.
  609.  
  610.     If want to use DES with MSCHAP (this is more efficient for
  611.     authentication), then you also give configure the --enable-mschapdes
  612.     option.  This will ensure that the DES calculation is done in the daemon.
  613.     A key will need to be obtained from Microsoft and used to replace the
  614.     definition of MSCHAP_KEY in the file mschap.h. If you're thinking by now
  615.     that this is all too much trouble, you're right.
  616.  
  617. Q). Can I do wtmp-style logging like xtacacd used to do?
  618. A). Wtmp file logging is supported. The "-u <wtmpfilename>" command
  619.     line flag can be used to specify a filename which will be used for
  620.     logging wtmp style records instead of the regular T+ accounting
  621.     records.
  622.  
  623.     wtmp records are generated into wtmpfilename. Since file locking is
  624.     also used when writing to wtmpfilename, the usual provisos regarding
  625.     NFS and locking (see accounting above) should be observed.
  626.  
  627.     To generate correct wtmp log records, the NAS needs to be configured
  628.     as follows:
  629.  
  630.     aaa accounting exec stop-only tacacs+
  631.     aaa accounting network stop-only tacacs+
  632.     aaa accounting system start-stop tacacs+
  633.  
  634. Q) How does TACACS compare to RADIUS?
  635. A) Cisco provided a good summary in general and somewhat specific to Cisco
  636.    products here:
  637.    http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080094e99.shtml#comparing
  638.