1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869
|
TAC_PLUS Developer's Kit vF4.0.4.alpha
--------------------------------------
Author: Lol Grant
Note: this is a DEVELOPER'S KIT. You probably shouldn't be using this
if you don't need source code. Instead, consider using CiscoSecure,
Cisco's supported, commercial Tacacs+ daemon.
Copyright (c) 1995-2000 by Cisco systems, Inc.
Permission to use, copy, modify, and distribute modified and
unmodified copies of this software for any purpose and without fee is
hereby granted, provided that (a) this copyright and permission notice
appear on all copies of the software and supporting documentation, (b)
the name of Cisco Systems, Inc. not be used in advertising or
publicity pertaining to distribution of the program without specific
prior permission, and (c) notice be given in supporting documentation
that use, modification, copying and distribution is by permission of
Cisco Systems, Inc.
Cisco Systems, Inc. makes no representations about the suitability
of this software for any purpose. THIS SOFTWARE IS PROVIDED ``AS
IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
Please NOTE: None of the TACACS code available here comes with any
warranty or support, however, comments or questions may be addressed
to Cisco systems via email at the address:
customer-service@cisco.com (or more simply)
cs@cisco.com
and we will do our best to handle them, though we cannot guarantee a
timely response, as this code is UNSUPPORTED. Be sure you've read this
user's guide, including the frequently asked questions include in it,
before posting.
Cisco systems also maintains an extensive World Wide Web site at
http://www.cisco.com/
In addition, there are two mailing lists which may be of interest to
users of Tacacs+.
The first is a mailing list run by spot.Colorado.EDU which discusses
many things pertaining to Cisco products. It is not run by Cisco
Systems, Inc. and is not part of Cisco's formal service request
channels, however, many knowledgeable people, including staff members
of Cisco Systems, Inc. voluntarily read and respond on the list.
Requests to be added to or deleted from the list at spot.Colorado.EDU,
along with other administrative issues concerning it can be sent to:
cisco-request@spot.Colorado.EDU
There is also a relatively new list called TACPLUS-L, run by
disaster.com, created for the purpose of information exchange between
TACACS+ Users. It is intended as a supplement to the list at
spot.Colorado.EDU, aiding TACACS+ users and prospective users in many
issues including but not limited to technical support, bug reports and
workarounds, configuration information, recommendations for future
versions of TACACS+, and general talk about TACACS+ development,
implementation, administration, etc.
Please note that neither of these lists is in fact connected with
Cisco Systems, Inc. or any of its subsidiaries. Standard etiquette
rules apply.
To subscribe to the TACPLUS-L list, send a message to
tacplus-l-request@disaster.com
In the body of the letter, enter
SUBSCRIBE TACPLUS-L your Name
to be automatically added, or visit their web page at
http://www.disaster.com/tacplus/.
Also, Robert Kiessling maintains a TACACS+ FAQ at
http://www.easynet.de/tacacs-faq.
Lastly, I am always interested in seeing contributed patches, so
consider mailing any modifications you make, as context diffs (be sure
to indicate with the version your patches are based on), to
tacacs-patches@cisco.com. As always, no support is implied, nor any
assurance that patches will be made available via ftp (though that is
my intent) or incorporated into any code.
Definitions and Terms
---------------------
NAS --- A Network Access Server e.g. a Cisco box, or any other
*client* which makes tacacs+ authentication and authorization
requests, or generates Tacacs+ accounting packets.
Daemon -- A program which services network requests for authentication
and authorization, verifies identities, grants or denies
authorizations, and logs accounting records.
passwd(5) files -- files conforming to Unix password style format, as
documented in section 5 of the Unix manuals.
AV pairs -- strings of text in the form "attribute=value" sent between a
NAS and a tacacs+ daemon as part of the Tacacs+ protocol.
Since a NAS is sometimes referred to as a server, and a daemon is also
often referred to as a server, the term "server" has been avoided here
in favor of the less ambiguous terms "NAS" and "Daemon".
TACACS, XTACACS and TACACS+
---------------------------
Note that there are now at least 3 versions of authentication protocol
that people commonly refer to as "TACACS".
The first is ordinary tacacs, which was the first one offered on Cisco
boxes and has been in use for many years. The second is an extension
to the first, commonly called Extended Tacacs or XTACACS, introduced
in 1990.
The third one is TACACS+ (or T+ or tac_plus) which is what is documented
here. TACACS+ is NOT COMPATIBLE with any previous versions of tacacs.
In addition to the 3 versions of tacacs running on Cisco boxes, the
fact that we distribute the source code to the daemon has meant that
additional implementations of tacacs daemons have been produced by
people who have made modifications to our source code.
BUILDING TAC_PLUS
-----------------
Tac_plus is known to build and run on the following platforms:
AIXv3.2 (using -DAIX and bsdcc. See tac_plus.h for more details).
HP/UX A.09.01 using -DHPUX
i86 Solaris 2.4 (SUNOS 5.4), using SUNpro SW2.0.1 & -DSOLARIS
Sun4 Solaris 2.4 using SUNpro SC3.0.1 and -DSOLARIS
SUNOS 4.1.2 sparc-2
SUNOS 4.1.3
MIPS R3K SGI IRIX 4.05F (using -DMIPS)
BSDI BSD/386 1.1 (using -DBSDI)
FREEBSD 2.0-RELEASE (using -DFREEBSD)
LINUX 1.2.8 (using -DLINUX)
Sun4 Solaris 2.6 using gcc 2.9
To build tac_plus, untar the tarfile distribution into a clean
directory e.g.
tar -xvf tac_plus.tar
Edit the top of the Makefile to select the appropriate defaults
for your system. Then type
make tac_plus
The default version can authenticate using its internal database,
s/key or passwd(5) style files. Authorization is done via the
internal database or via calls to external programs, which the
administrator configures.
To use S/KEY, you must obtain and build the s/key library (libskey.a)
yourself. You can then compile in S/KEY support per the instructions
for S/KEY in the Makefile. I got my S/KEY code originally from
crimelab.com but now it appears the only source is ftp.bellcore.com. I
suggest you try a web search for s/key source code.
Note: S/KEY is a trademark of Bell Communications Research (Bellcore).
Should you need them, there are routines for accessing password files
(getpwnam,setpwent,endpwent,setpwfile) in pw.c.
Lastly, you may also need to add lines to your /etc/services file to
get tacacs+ to work correctly e.g. something along the lines of:
tacacs tcp/49
You'll need to consult your system manuals for exact details of how to
do this.
A NOTE ABOUT ARAP, MSCHAP AND DES
---------------------------------
If you have access to a DES library which implements the calls:
int des_init();
void des_setkey();
void des_endes();
void des_done();
then you can define DES in tac_plus.h and link tac_plus with your DES
library. This is recommended, as it will allow you to process ARAP and MSCHAP
requests on your daemon, which is more efficient, and also more secure
than processing them on the NAS.
If you don't have access to des (which is U.S. export controlled), you
can simply leave DES undefined in tac_plus.h. ARAP and MSCHAP
authentication will still work, but it will be slightly less
efficient, since the NAS will attempt to get the daemon to do the DES
calculation before falling back to the alternative of calculating DES
on the NAS. It's also slightly less secure, because if someone
discovers your encryption key, they can then download ARAP and MSCHAP
secrets from your daemon.
Note that this issue arises solely because U.S. government regulations
currently make it difficult to export the source code for DES outside
the US and Canada, which is why it is not included in this
distribution.
Lastly, this limitation of MSCHAP, ARAP and DES has no bearing on the
use of des passwords for regular logins. Regular logins also use DES
but they do it via the "crypt" system call, which is usually found in
a library on the Unix host where you compile your daemon.
There are additional restrictions on doing MSCHAP (see the FAQ later
in this document).
CONFIGURING TAC_PLUS
---------------------
Tac_plus is configured via a single configuration file. You can create
a configuration file from scratch or, if you have passwd(5) and
supplementary files from earlier versions of tacacs, you can convert
these to configuration file format by running the supplied perl script
convert.pl.
CONVERTING EXISTING PASSWD(5) FILES
-----------------------------------
To convert an existing passwd(5) file e.g. one used with an older
version of tacacs, use the convert.pl perl script as follows:
convert.pl <passwd file> [-g] [<supplementary file>]
1). If you have no supplementary file, simply omit it.
2). If the groupid field of your passwd file does NOT represent a
valid acl number (e.g if it's really a unix passwd file this field is
a group id, not an acl number), just omit the -g flag.
The rest of this document assumes that you are configuring tac_plus
from scratch.
CONFIGURING TAC_PLUS FROM SCRATCH
---------------------------------
A configuration file consists of some top-level directives for setting
defaults and for setting up the encryption key, followed by a
declaration for each user and group you want to configure. Within
each user or group declaration, there are declarations for
authenticating and authorizing that user.
1). Configuring the encryption key
If you want tac_plus to encrypt its packets (and you almost certainly
*DO* want this, as there can be usernames and passwords contained in
these packets), then you must specify an encryption key in the
configuration file. The identical key must also be configured on any
NAS which communicates with tac_plus.
This is done using the statement
key = "your key here"
NOTE: You only need double quotes on the daemon if your key contains
spaces.
Confusingly, even if your key does contain spaces, you should NEVER
use double quotes when you configure the matching key on the NAS.
During debugging, it may be convenient to temporarily switch off
encryption by not specifying any key. Be careful to remember to
switch encryption back on again after you've finished debugging.
The current code does not support host-specific keys (left as an
exercise to the reader).
On the NAS, you also need to configure the *same* key. Do this by
issuing:
aaa new-model
tacacs-server key <your key here>
COMMENTS IN CONFIGURATION FILES
-------------------------------
Comments can appear anywhere in the configuration file, starting with
the # character and extending to the end of the current line. Should
you need to disable this special meaning of the # character, e.g. if
you have a password containing a # character, simply enclose the string
containing it within double quotes.
CONFIGURING USERS AND GROUPS
----------------------------
Each user may belong to a group (but only one group). Each group may
in turn belong to one other group and so on ad infinitum.
Users and groups are declared as follows. Here we declare two users
"fred" and "lily", and two groups, "admin" and "staff".
Fred is a member of group "admin", and group "admin" is in turn a
member of group "staff". Lily is not a member of any group.
user = lily {
# user lily is not a member of any group
# and has nothing else configured as yet
}
user = fred {
# fred is a member of group admin
member = admin
}
group = admin {
# group admin is a member of group staff
member = staff
}
group = staff {
# group staff is not a member of any group
}
RECURSION AND GROUPS
--------------------
In general, when the daemon looks up values e.g. passwords, it will
look first to see if the user has her own password. If not, it looks
to see if she belongs to a group and if so, whether the group has a
password defined. If not, this process continues through the hierarchy
of groups (a group can be a member of another group) until a value is
found, or there are no more groups.
This recursive process occurs for lookups of expiration dates, for
pap, arap and chap "secrets", and also for authorization parameters (see
later).
A typical configuration technique is thus to place users into groups
and specify as many groupwide characteristics in the group declaration
as possible. Then, individual user declarations can be used to
override the group settings for selected users as needed.
CONFIGURING USER AUTHENTICATION
-------------------------------
User Authentication can be specified separately for PAP, ARAP, CHAP,
and normal logins. In addition, a user global authentication method
can be given that will be used if a per-protocol method is not
specified.
PAP, ARAP, CHAP, and global user authentication must be given in clear
text.
The following assigns the user mary five different passwords for ARAP,
inbound and outbound CHAP, inbound PAP, outbound PAP, and normal login
respectively:
user = mary {
arap = cleartext "arap password"
chap = cleartext "chap password"
pap = cleartext "inbound pap password"
opap = cleartext "outbound pap password"
login = des XQj4892fjk
}
The following assigns the user agnes a single password for all the
above types of login (except outbound PAP):
user = agnes {
global = cleartext "Agnes global password"
}
NOTE: you cannot use a global user password for outbound PAP. This is
because outbound PAP is implemented by sending the password from the
daemon to the NAS. This is a security issue if the TACACS+ key is ever
compromised.
There are 3 ways to authenticate a user for login.
1). You can include a DES (or cleartext) password for a user or for a
group that s/he is a member of, viz:
user = joe {
member = admin
# this is lily's encrypted DES password. It overrides the admin
# group's password
login = des XQkR21zMB0TDU
}
user = fred {
# fred is a member of group admin. He inherits the group's password
# as he does not have his one of his own.
member = admin
}
group = admin {
# group admin has a cleartext password which all members share
# unless they have their own password defined
login = cleartext foobar
}
If no password is needed for this user, this can be accomplished with
the 'nopassword' option:
user = foo {
login = nopassword
}
NOTE: The C program built from generate_passwd.c may be used to
hand-generate encrypted passwords, or they may be taken from a Unix
passwd (or shadow) file.
2). Authentication using passwd(5) files.
For selected users, you can perform DES authentication using existing
passwd(5) files instead of entering the password into the
configuration file directly (though using passwd(5) files is
noticeably less efficient for large files).
You can specify this behavior per-user, by naming a passwd(5) file in
the password declaration (instead of giving a DES password), as
follows:
user = fred {
# look in file /etc/tac_plus_passwords to authenticate this user
login = file /etc/tac_plus_passwords
}
3). Authentication using s/key.
If you have successfully built and linked in a suitable s/key library
and compiled tac_plus to use s/key, you can then specify that a user
be authenticated via s/key, as follows:
user = fred {
login = skey
}
RECURSIVE PASSWORD LOOKUPS
---------------------------
As stated earlier, authentication passwords are looked up recursively:
The daemon looks first to see if the user has her own password. If
not, it looks to see if she belongs to a group which has a
password. This process recurses through the hierarchy of groups (a
group can be a member of another group) until a password is found, or
there are no more groups.
CONFIGURING DEFAULT AUTHENTICATION
-----------------------------------
By default, an unrecognized user will be denied authentication (NOTE:
there is no way to authenticate someone with no username).
At the top level of the configuration file, you can set the default
authentication to use a passwd(5) file, viz:
default authentication = file /etc/passwd
The effect of this statement is that if a user does not appear in the
configuration file, the daemon will attempt to authenticate the user
using passwords from this file i.e. /etc/passwd in this example.
If you have passwd(5) files from previous versions of tacacs daemons,
this facility allows you to authenticate using the passwd(5) from
older versions of tacacs, while you migrate to using the new
configuration file.
CONFIGURING EXPIRY DATES
------------------------
An entry of the form:
user = lol {
expires = "MMM DD YYYY"
password = cleartext "bite me"
}
will cause the user's passwords to become invalid, starting on the
expiry date. The only valid date format is e.g. "Jan 1 1980". Case is
NOT significant.
A expiry warning message is sent to the user when she logs in,
starting at 14 days before the expiration date.
On expiry, the administrator must re-set the expiry date in the
configuration file in order to grant continued access. Expiry applies
to all password types except "file" passwords.
If passwd(5) files are being used for authentication, the "expires"
field in the configuration file is not consulted. Instead, the daemon
looks at the the "shell" field of the password file entry for a valid
expiry date.
If Solaris shadow password files are used for authentication, the
"expires" field in the configuration file is not consulted. The expiry
field from the shadow password file (if it exists) is used as the
expiration date.
CONFIGURING AUTHENTICATION ON THE NAS
-------------------------------------
On the NAS, to configure login authentication on all lines (including
vty and console lines)
aaa new-model
aaa authentication login default tacacs+
NOTE: As soon as you issue this command, you will no longer be able to
create new logins to your NAS without a functioning tacacs+ daemon
appropriately configured with usernames and password, so make sure you
have this ready.
As a safety measure while setting up, we suggest you configure an
enable secret and make it the last resort authentication method, so
if your tacacs+ daemon fails to respond you will be able to use the
NAS enable password to login. To do this, configure:
enable secret foo
aaa authentication login default tacacs+ enable
If all else fails, and you find yourself locked out of the NAS due to
a configuration problem, the section on "recovering from lost
passwords" on Cisco's CCO web page will help you dig your way out.
CONFIGURING ENABLE PASSWORDS
----------------------------
The default privilege level for an ordinary user on the NAS is usually
1. When a user enables, she can reset this level to a value between 0
and 15 by using the NAS "enable" command. If she doesn't specify a
level, the default level she enables to is 15.
You can enable via tacacs+ e.g. by configuring on the NAS:
aaa authentication enable default tacacs+
then whenever you attempt to enable, an authentication request is sent
with the special username $enab<n>$ where <n> is the privilege level
you are attempting to enable to.
(Note: in order to be compatible with earlier versions of tacacs, when
the requested enable level is 15, the daemon will also try the
username $enable$ before trying username $enab15$).
For example, with the above declaration, in order to enable on the
NAS, you need a user declaration like this one, on the daemon:
user = $enab15$ {
login = cleartext "the enable password for level 15"
}
Note: Be aware that this does have the side effect that you now have a
user named $enab15$ who can then login to your NAS if she knows the
enable password.
Here is a similar declaration allowing users to enable to level 4:
user = $enab4$ {
login = des bsoF4OivQCY8Q
}
CONFIGURING AUTHORIZATION
-------------------------
Authorization must be configured on both the NAS and the daemon to
operate correctly. By default, the NAS will allow everything until you
configure it to make authorization requests to the daemon.
On the daemon, the opposite is true: The daemon will, by default, deny
authorization of anything that isn't explicitly permitted.
Authorization allows the daemon to deny commands and services
outright, or to modify commands and services on a per-user
basis. Authorization on the daemon is divided into two separate parts:
commands and services.
AUTHORIZING COMMANDS
--------------------
Exec commands are those commands which are typed at a Cisco exec
prompt. When authorization is requested by the NAS, the entire command
is sent to the tac_plus daemon for authorization.
Command authorization is configured by specifying a list of
egrep-style regular expressions to match command arguments (see the
supplied man page, regexp.3, for a full description of regular
expressions) and an action which is "deny" or "permit".
The following configuration example permits user Fred to run the
following commands:
telnet 131.108.13.<any number> and
telnet 128.<any number>.12.3 and
show <anything>
All other commands are denied (by default).
user=fred {
cmd = telnet {
# permit specified telnets
permit 131\.108\.13\.[0-9]+
permit 128\.[0-9]+\.12\.3
}
cmd = show {
# permit show commands
permit .*
}
}
NOTE: If an argument list you specify contains spaces or tabs, you
must enclose it in double quotes.
The command and arguments which the user types gets matched to the
regular expressions you specify in the configuration file (in order of
appearance). The first successful match performs the associated
action (permit or deny). If there is no match, the command is denied
by default.
Conversely, the following configuration example can be used to deny
the command:
telnet 131.108.13.<any number>
and permit all other arguments, since the last line will match any
argument list. All other commands and services are permitted due to
the "default service = permit" clause.
Note: the default statement must be the first in the user clause
user=fred {
default service = permit
cmd = telnet {
# allow all fred's telnet commands except to 131.108.13.*
deny 131\.108\.13\.[0-9]+
permit .*
}
}
Note: Matches are not anchored, so "deny 131.108.13.[0-9]+" matches
anywhere in the command. To anchor the match, use ^ at the beginning
of the regular expression.
Note: When a command has multiple arguments, users may enter them in
many different permutations. It can be cumbersome to create regular
expressions which will reliably authorize commands under these
conditions, so administrators may wish to consider other methods of
performing authorization e.g. by configuring NAS-local privileged
enable levels on the NAS itself.
COMMAND EXPANSION
-----------------
For command authorization, the Cisco NAS expands all commands to their
full names e.g. when you type "config t" on the NAS, this will be
expanded to "configuration terminal" before being sent to the daemon
so that you don't need to list all the possible contractions of a
command.
CONFIGURING DEFAULT AUTHORIZATION
---------------------------------
There are 3 places where defaults for authorization may be
configured. Unless specified to the contrary, the default is always to
deny authorization.
1). To override the default denial of authorization for users who are
not explicitly listed in the configuration file, the ersatz user
DEFAULT, if defined, can be used for authorizing such users, viz:
default authentication = file /etc/passwd
user = DEFAULT {
service = ppp protocol = ip {
addr-pool=foobar
}
}
In this example, users who do not appear elsewhere will be
authenticated via the /etc/passwd file, and authorized by the contents
of the user = DEFAULT entry.
Note: For backward compatibility, the directive,
default authorization = permit
may still be specifed at the top level of the configuration file. This
overrides the default denial of authorization for users who are not
explicitly listed in the configuration file, permitting all
authorization requests for such users.
2). At the user level i.e. inside the braces of a user declaration,
the default for a user who doesn't have a service or command
explicitly authorized is to deny that service or command. The
following directive will permit the service or command by default
instead:
user = lol {
default service = permit
}
NOTE: This directive must appear first inside the user declaration.
3). At the service authorization level i.e. inside the braces of a
service declaration, arguments in an authorization request are
processed according to the algorithm described later. Some actions
when authorizing services (e.g. when matching attributes are not
found) depend on how the default is configured. The following
declaration changes the default from deny to permit for this user and
service.
user = lol {
service = exec {
default attribute = permit
}
}
NOTE: This directive must appear before any others inside the service
declaration.
NOTE: for command authorization (as opposed to service authorization
being discussed here), you specify deny .* or permit .* as the last
line of the regular expression matches to create default behavior.
AUTHORIZING EXEC STARTUP
-------------------------
If you authorize some exec commands, you implicitly agree to allow
that user to start an exec (it doesn't make sense to permit exec
commands if an exec can't be started to run those commands)
In addition to agreeing to allow an exec to start, you can supply some
parameters whenever an exec starts e.g. an autocommand, a dialback
string or a connection access list (acl).
In the example below, when an exec is started on the NAS, an acl of 4
will be returned to the NAS:
user=fred {
# this following line permits an exec to start and permits
# all commands and services by default
default service = permit
service = exec {
# When an exec is started, its connection access list will be 4.
# It also has an autocmd.
acl = 4
autocmd = "telnet foobar"
}
cmd = telnet {
# allow all fred's telnet commands except telnet to 131.108.13.*
deny 131\.108\.13\.[0-9]+
permit .*
}
}
NOTE: specifying an autocommand, or any other exec services, is part
of EXEC AUTHORIZATION. For it to work, you must also configure exec
authorization on your NAS e.g.
aaa authorization exec tacacs+
AUTHORIZING EXEC, SLIP, PPP and ARAP SERVICES
----------------------------------------------
Authorizing exec, slip, PPP and arap services is done quite
differently from command authorization.
When authorizing these services, the NAS sends a request containing a
number of attribute-value (AV) pairs, each having the form
attribute=value
(Note: during debugging, you may see AV pairs whose separator
character is a "*" instead of a "=" sign. This is to signify that the
value in a pair is optional. An "=" sign indicates a mandatory
value. A "*" denotes an optional value).
e.g. a user starting ppp/ip using an address of 131.108.12.44 would
generate a request with the following AV pairs:
service=ppp
protocol=ip
addr*131.108.12.44
You can use the NAS debugging command
debug aaa authorization
to see what authorization AV pairs are being used by the NAS. Note: If
you are not on the router console, you will also need to issue a
'terminal monitor' command to see debug output.
THE AUTHORIZATION PROCESS
-------------------------
Authorizing a single session can result in multiple requests being
sent to the daemon. For example, in order to authorize a dialin ppp
user for IP, the following authorization requests will be made from
the NAS:
1). An initial authorization request to startup ppp from the exec,
using the AV pairs service=ppp, protocol=ip, will be made (Note: this
initial request will be omitted if you are autoselecting ppp, since
you won't know the username yet).
This request is really done to find the address for dumb PPP (or SLIP)
clients who can't do address negotiation. Instead, they expect you to
tell them what address to use before PPP starts up, via a text message
e.g. "Entering PPP. Your address is 1.2.3.4". They rely on parsing
this address from the message to know their address.
2). Next, an authorization request is made from the PPP subsystem to
see if ppp's LCP layer is authorized. LCP parameters can be set at
this time (e.g. callback). This request contains the AV pairs
service=ppp, protocol=lcp.
3). Next an authorization request to startup ppp's IPCP layer is made
using the AV pairs service=ppp, protocol=ipcp. Any parameters returned
by the daemon are cached.
4). Next, during PPP's address negotiation phase, each time the remote
peer requests a specific address, if that address isn't in the cache
obtained in step 3, a new authorization request is made to see if the
peers requested address is allowable. This step can be repeated
multiple times until both sides agree on the remote peer's address or
until the NAS (or client) decide they're never going to agree and they
shut down PPP instead.
As you can see from the above, a program which plans to handle
authorization must be able to handle a variety of requests and respond
appropriately.
AUTHORIZATION RELIES ON AUTHENTICATION
--------------------------------------
Since we pretty much rely on having a username in authorization
requests to decide which addresses etc. to hand out, it is important
to know where the username for a PPP user comes from. There are
generally 2 possible sources
1). You force the user to authenticate by making her login to the exec
and you use that login name in authorization requests. This username
isn't propagated to PPP by default. To have this happen, you generally
need to configure the "if-needed" method, e.g.
aaa authentication login default tacacs+
aaa authentication ppp default if-needed
2). Alternatively, you can run an authentication protocol, PAP or CHAP
(CHAP is much preferred), to identify the user. You don't need an
explicit login step if you do this (so it's the only possibility if
you are using autoselect). This authentication gets done before you
see the first LCP authorization request of course. Typically you
configure this by doing:
aaa authentication ppp default tacacs+
int async 1
ppp authentication chap
If you omit either of these authentication schemes, you will start to
see authorization requests in which the username is missing.
CONFIGURING SERVICE AUTHORIZATION
---------------------------------
A list of AV pairs is placed in the daemon's configuration file in
order to authorize services. The daemon compares each NAS AV pair to
its configured AV pairs and either allows or denies the service. If
the service is allowed, the daemon may add, change or delete AV pairs
before returning them to the NAS, thereby restricting what the user is
permitted to do.
The complete algorithm by which the daemon processes its configured
AV pairs against the list the NAS sends, is given below.
The Authorization Algorithm
---------------------------
Find the user (or group) entry for this service (and protocol), then
for each AV pair sent from the NAS:
If the AV pair from the NAS is mandatory:
a). look for an exact attribute,value match in the user's
mandatory list. If found, add the AV pair to the output.
b). If an exact match doesn't exist, look in the user's
optional list for the first attribute match. If found, add the
NAS AV pair to the output.
c). If no attribute match exists, deny the command if the
default is to deny, or,
d). If the default is permit, add the NAS AV pair to the
output.
If the AV pair from the NAS is optional:
e). look for an exact attribute,value match in the user's
mandatory list. If found, add DAEMON's AV pair to output.
f). If not found, look for the first attribute match in the
user's mandatory list. If found, add DAEMONS's AV pair to output.
g). If no mandatory match exists, look for an exact
attribute,value pair match among the daemon's optional AV
pairs. If found add the DAEMON's matching AV pair to the
output.
h). If no exact match exists, locate the first attribute match
among the daemon's optional AV pairs. If found add the
DAEMON's matching AV pair to the output.
i). If no match is found, delete the AV pair if the default is
deny, or
j). If the default is permit add the NAS AV pair to the output.
k). After all AV pairs have been processed, for each mandatory
DAEMON AV pair, if there is no attribute match already in the
output list, add the AV pair (but add only ONE AV pair for each
mandatory attribute).
RECURSIVE AUTHORIZATION
-----------------------
Remember that authorization is also recursive over groups, in the same
way that password lookups are recursive. Thus, if you place a user in
a group, the daemon will look in the group for authorization
parameters if it cannot find them in the user declaration.
EXAMPLES
--------
key = "your key here"
user=fred {
login = des mEX027bHtzTlQ
name = "Fred Flintstone"
member = administrators
expires = "May 23 2005"
arap = cleartext "Fred's arap secret"
chap = cleartext "Fred's chap secret"
service = exec {
# When Fred starts an exec, his connection access list is 5
acl = 5
# We require this autocmd to be done at startup
autocmd = "telnet foo"
}
# All commands except show system are denied for Fred
cmd = show {
# Fred can run the following show command
permit system
deny .*
}
service = ppp protocol = ip {
# Fred can run ip over ppp only if he uses one
# of the following mandatory addresses. If he supplies no
# address, the first one here will be mandated
addr=131.108.12.11
addr=131.108.12.12
addr=131.108.12.13
addr=131.108.12.14
# Fred's mandatory input access list number is 101
inacl=101
# We will suggest an output access list of 102, but the NAS may
# choose to ignore or override it
optional outacl=102
}
service = slip {
# Fred can run slip. When he does, he will have to use
# these mandatory access lists
inacl=101
outacl=102
}
}
user = wilma {
# Wilma has no password of her own, but she's a group member so
# she'll use the group password if there is one. Same for her
# password expiry date
member = admin
}
group = admin {
# group members who don't have their own login password will be looked
# up in /etc/passwd
login = file /etc/passwd
# group members who have no expiry date set will use this one
expires = "Jan 1 1997"
}
USING PROGRAMS TO DO AUTHORIZATION
----------------------------------
There are some limitations to the authorization that can be done using
a configuration file. The main ones are that you're constrained by the
algorithm the daemon uses, and that the configuration is basically
static, so if you're trying to use it to allocate dynamic things (such
as addresses from a pool) that vary over time, you need another
mechanism.
One solution is to arrange for the daemon to call your own
user-supplied programs to control authorization. These "callouts"
permit almost complete control over authorization, allowing you to
read all the fields in the authorization packet sent by the NAS
including all its AV pairs, and to set authorization status and send a
new set of AV pairs to the NAS in response.
USING AV PAIRS FOR AUTHORIZATION
--------------------------------
During authorization, the NAS sends an authorization request packet
containing various fields of interest and a set of AV pairs (see the
tacacs+ protocol specification for a list of fields and pairs).
Fields from the authorization packet can be supplied to the programs
you call on their command line, by using the appropriate dollar
variables in the configuration file (see below).
AV pairs from the authorization packet are fed to the program's
standard input, one per line. The program is expected to process the
AV pairs and write them to its standard output, one per line. What
happens then is determined by the exit status of the program.
NOTE: AV pairs are text strings with the format
attribute=value. Unlike the configuration file which allows spaces
when specifying AV pairs, there should be no spaces surrounding the
"=" sign when using the programmatic interface.
CALLING SCRIPTS BEFORE AUTHORIZATION
------------------------------------
You can specify a per-user program to be called before any other
attempt to authorize is made by using a "before" clause e.g.
user = auth1 {
before authorization "/usr/local/bin/pre_authorize $user $port $address"
}
The AV pairs sent from the NAS will be supplied to this program's
standard input, one pair per line.
Fields from the initiating authorization packet which the NAS sends to
the daemon can also be passed to the program by using dollar variables
in the command line. A complete list of available variables is as
follows (consult the API specification for more details).
user -- user name
name -- Nas name
port -- Nas port
address -- Nac address (remote user location)
priv -- privilege level (a digit, 0 to 15)
method -- (a digit, 1 to 4)
type -- (a digit, 1 to 4)
service -- (a digit, 1 to 7)
status -- (pass, fail, error, unknown)
Unrecognized variables will appear as the string "unknown".
If the program returns a status of 0, authorization is unconditionally
permitted. No further processing is done on this request and no AV
pairs are returned to the NAS.
If the program returns a status of 1, authorization is unconditionally
denied. No further processing is done on this request and no AV pairs
are returned to the NAS.
If the program returns a status of 2, authorization is permitted. The
program is expected to modify the AV pairs that it receives on its
standard input (or to create entirely new ones) and to write them, one
per line, to its standard output. The new AV pairs will be sent to the
NAS with a status of AUTHOR_STATUS_PASS_REPL. No further processing
takes place on this request.
If the program returns a status of 3, authorization is denied, but all
attributes returned by the program via stdout are returned to the
NAS. Also, whatever the program returns on stderr is placed into the
server-msg field and returned to the NAS as well.
Any other status value returned from the program will cause an error
to be returned to the NAS.
Note that a status of 2 is not acceptable when doing command
authorization.
CALLING PROGRAMS AFTER AUTHORIZATION
------------------------------------
You can specify a per-user program to be called after authorization
processing has been carried out by the daemon (but before the
authorization status and AV pairs have been transmitted to the NAS).
The program can optionally modify the AV pairs being sent back to the
NAS and change the authorization status if required.
group = auth1 {
# call /usr/local/bin/post_authorize passing it the username, port
# and current authorization status.
after authorization "/usr/local/bin/post_authorize $user $port $status"
}
The AV pairs resulting from the authorization algorithm that the
daemon proposes to return to the NAS, are supplied to the program on
standard input, one AV pair per line, so they can be modified if
required.
Fields from the incoming authorization packet which the NAS sent to
the daemon can also be passed to the program on its command line by
specifying dollar variables in the command line (see previous
section).
The program is expected to process the AV pairs and write them to its
standard output, one per line. What happens then is determined by the
exit status of the program:
If the program returns a status of 0, authorization continues as if
the program had never been called. Use this if e.g. you just want a
program to send mail when an authorization occurs, without otherwise
affecting normal authorization.
If the program returns a status of 1, authorization is unconditionally
denied. No AV pairs are returned to the NAS. No further authorization
processing occurs on this request.
If the program returns a status of 2, authorization is permitted and
any AV pairs returned from the program on its standard output are sent
to the NAS in place of any AV pairs that the daemon may have
constructed.
Any other value will cause an error to be returned the the NAS by the
daemon.
WARNINGS AND CAUTIONS
---------------------
Customers attempting to write authorization scripts will find the NAS
debugging command "debug aaa authorization" invaluable.
Pre and post authorization programs are invoked by handing the command
line to the Bourne shell. On many Unix systems, if the shell doesn't
find the specified program it returns a status of one, which denies
authorization. However, at least one Unix system (BSDI) returns a
status code of 2 under these circumstances, which will permit
authorization, and probably isn't what you intended.
Note also that if your program hangs, the authorization will time out
and return an error on the NAS, and you'll tie up a process slot on
the daemon host, eventually running out of resources. There is no
special code to detect this in the daemon.
Unless you make special arrangements, the daemon will run as root and
hence the programs it invokes will also run as root, which is a
security weakness. It is strongly recommended that you use absolute
pathnames when specifying programs to execute, and that you use the
Makefile options TAC_PLUS_USERID and TAC_PLUS_GROUPID so that the
daemon is not running as root when calling these programs,
The daemon communicates with pre and post authorization programs over
a pair of pipes. Programs using the standard i/o library will use full
buffering in these circumstances. This shouldn't be a problem for most
programs, since they'll read AV pairs till they see end of file on
input, and they'll flush all output when they exit.
Note that when avpairs containing spaces are listed in the
configuration file, you need to enclose them in double quotes so that
they are parsed correctly. Avpairs which are returned via standard
output do not need delimiters and so should not be enclosed in double
quotes.
CONFIGURING AUTHORIZATION ON THE NAS
------------------------------------
If authorization is not explicitly configured on the NAS, no
authorization takes place i.e. effectively, everything is
permitted. Note that this is the converse of what happens on the
daemon, where anything not explicitly permitted is denied by default.
To configure command authorization on the NAS, issue the following NAS
configuration commands:
aaa authorization commands 1 tacacs+
aaa authorization commands 15 tacacs+
This will make the NAS send tacacs+ requests for all level 1 (ordinary
user) and level 15 (privileged level) commands on all lines/interfaces.
NOTE: As soon as you configure the above on your NAS, you will only be
permitted to execute NAS commands which are permitted by your tacacs+
daemon. So make sure you have configured, on the daemon, an
authenticated user who is authorized to run commands, or you will be
unable to do much on the NAS after turning on authorization.
Alternatively, or in addition, you may also want to configure the
following:
aaa authorization commands 1 tacacs+ if-authenticated
This will use tacacs+ authorization for level 1 (user-level commands)
but if problems arise, you can just switch off the tacacs+ server and
authorization will then be granted to anyone who is authenticated.
The following daemon configuration should be sufficient to ensure that
you can always login as username "admin" (with a suitable password)
and run any command as that user:
user = admin {
default service = permit
login = des kppPfHq/j6gXs
}
ACCOUNTING
-----------
There is only one configurable accounting parameter -- the accounting
file name. All accounting records are written, as text, to this
filename. The filename is configured as follows at the top-level of
the configuration file:
accounting file = <filename>
Since accounting requests occur (and are serviced) asynchronously, it
is necessary to lock the accounting file so that two writers don't
simultaneously update it. The daemon uses the fcntl call to do this
locking, so it is recommended that the accounting file reside on a
local filesystem. Although fcntl locking over NFS is supported on some
Unix implementations, it is notoriously unreliable. Even if your
implementation is reliable, locking is likely to be extremely
inefficient over NFS.
NAS CONFIGURATION
-----------------
To get accounting records equivalent to previous versions of tacacs,
the following is sufficient. "Stop" records contain elapsed time for
connections and exec sessions.
aaa accounting network stop-only tacacs+
aaa accounting exec stop-only tacacs+
CONFIGURING CALLBACK WITH TACACS+
---------------------------------
Note: Callback is available only in IOS 11.1 and later, and can only
be controlled via Tacacs+ for ASYNC lines. ISDN callback can be
configured on the NAS but cannot be controlled via AAA.
Here is an example of AAA configuration (with exec and network
accounting enabled):
NAS configuration:
aaa new-model
tacacs-server host XX.XX.XX.XX
tacacs-server key fookey
aaa accounting exec wait-start tacacs+
aaa accounting network wait-start tacacs+
! Example of AAA configuration for Exec:
aaa authentication login execcheck tacacs+
aaa authorization network tacacs+
service exec-callback
:
line 4
login authentication execcheck
! Example of AAA configuration for ARAP:
aaa authentication arap arapcheck tacacs+
aaa authorization network tacacs+
arap callback
:
line 4
arap authentication arapcheck
! Example of AAA-specific configuration for PPP callback:
aaa new-model
aaa authentication ppp pppcheck tacacs+
aaa authorization network tacacs+
:
int async 6
ppp authentication chap pppcheck
ppp callback accept
Daemon configuration:
Example of remote TACACS+ server CONFIG file entry for username `foobar':
user = foobar {
arap = cleartext AAAA
login = cleartext LLLL
chap = cleartext CCCC
pap = cleartext PPPP
opap = cleartext OOOO
service = ppp protocol = lcp {
callback-dialstring=123456
}
service = arap {
callback-dialstring=2345678
}
service = exec {
callback-dialstring=3456789
callback-line=7
nocallback-verify=1
}
}
DEBUGGING CONFIGURATION FILES
-----------------------------
When creating configuration files, it is convenient to check their
syntax using the -P flag to tac_plus e.g.
tac_plus -P -C <config file name>
will syntax check the configuration file and print any error messages
on the terminal.
DEBUGGING A RUNNING SERVER
--------------------------
There is a myriad of debugging values that can be used in conjunction
with the -d flag to produce debugging output in /var/tmp/tac_plus.log.
For example, starting the daemon with
tac_plus -C CONFIG -d 16
will put authentication debugging into /var/tmp/tac_plus.log. You can
view this information by using the tail command.
tail -f /var/tmp/tac_plus.log
See the man page for more information.
CHANGING CONFIGURATIONS
-----------------------
To change a configuration file, you must edit the configuration file
and then send the daemon a SIGUSR1. This will cause it to reinitialize
itself and re-read the configuration file.
On startup, tac_plus creates the file /etc/tac_plus.pid , if possible,
containing its process id. If you invoke the daemon so that it listens
on a non-standard port, the file created is /etc/tac_plus.pid.<port>
instead, where <port> is the port number the daemon is listening on.
Assuming you are listening on the default port 49, something like the
following should work:
# kill -USR1 `cat /etc/tac_plus.pid`
It's a good idea to check that the daemon is still running after
sending it a SIGUSR1, since a syntactically incorrect configuration
file will cause the daemon to die.
NOTE: The perl script generate_passwd.pl may be used to hand-generate
encrypted passwords, or they may be taken from a Unix passwd file.
FREQUENTLY ASKED QUESTIONS
--------------------------
Q). Does T+ required a working DNS?
A). As distributed, whenever a START packet arrive, the daemon makes a
call to getpeername to find out the name of the requestor. Depending
entirely on how your Unix host is set up, this may make DNS
queries. If this is a problem, comment out the code in tac_plus.c
which does this, and just use ip addresses instead of host names.
Q). Is the "name" field used for anything
A). No. It's purely for documentation. I had once thought it might be
useful when outputting error messages, and that you might need the
information if you converted a passwd(5) style file, but no use is
currently made of the field.
Q). Why do I get PPP authorization failures because of "no username in
request" when I've already logged in and authenticated?
A). With "aaa authentication PPP default tacacs+", the ppp
authentication overrides the earlier login authentication. If the ppp
authentication fails, the username ends up blank. Changing the config
to "aaa authentication ppp default if-needed tacacs+" fixes this
problem.
Q). I'm sure I configured it correctly, but accounting still doesn't
work.
A). You will find that although you can configure accounting in 10.3,
and it outputs debug messages, it doesn't send any accounting
packets. This is because Accounting only works from 11.0 onwards.
Q). Does TACACS+ use a database instead of a flat (/etc/passwd like)
file to decrease search times, say if we are talking about a large
database of 40,000 users?
A). The TACACS+ authentication database is held internally as a hash
table. This makes lookup times fast and fairly linear, at the expense
of making the server use potentially large amounts of memory space.
NOTE: If you specify that the server uses passwd(5) files for
authentication, then you don't get this speed benefit, but you save
space.
If you're willing to write the code, it should be a relatively simple
matter to interface the code to a database scheme e.g. unix dbm files,
or some proprietary database package, if you wish.
Q). Is there any way to avoid having clear text versions of the
ARAP and CHAP secrets in the configuration file?
CHAP and ARAP require that the server knows the cleartext password (or
equivalently, something from which the server can generate the
cleartext password). Note that this is part of the definition of CHAP
and ARAP, not just the whim of some Cisco engineer who drank too much
coffee late one night.
If we encrypted the CHAP and ARAP passwords in the database, then we'd
need to keep a key around so that the server can decrypt them when
CHAP or ARAP needs them. So this only ends up being a slight
obfuscation and not much more secure than the original scheme.
In extended TACACS, the CHAP and ARAP secrets were separated from the
password file because the password file may be a system password file
and hence world readable. But with TACACS+'s native database, there
is no such requirement, so we think the best solution is to
read-protect the files. Note that this is the same problem that a
kerberos server has. If your security is compromised on the kerberos
server, then your database is wide open. Kerberos does encrypt the
database, but if you want your server to automatically restart, then
you end up having to "kstash" the key in a file anyway and you're back
to the same security problem.
So storing the cleartext password on the security server is really an
absolute requirement of the CHAP and ARAP protocols, not something
imposed by TACACS+.
We could have chosen a scheme where the NAS sends the challenge
information to the TACACS+ daemon and the daemon uses the cleartext
password to generate the response and returns that, but that means
that we must include specific protocol knowledge into the protocol for
both ARAP and CHAP and we would have to update the protocol every time
a new authentication protocol is added. Hence we decided to go with
the SENDPASS mechanism.
Note that the above doesn't apply to PAP. You can keep an inbound PAP
password des-encrypted, since all you need to do with it is verify
that the password the principal gave you is correct.
Q). How is the typical login authentication sequence done?
A). NAS sends START packet to daemon
Daemon send GETUSER containing login prompt to NAS
NAS prompts user for username
NAS sends pkt to daemon
Daemon sends GETPASS containing password prompt to the NAS
NAS prompts user for password
NAS sends pkt to daemon
Daemon sends accept, reject or error to NAS
Q). Is there a GUI for the configuration file?
A). No. Use your favourite text editor.
Q). What does "default service = permit" really do?
A). When a request comes in to authorize exec startup, or ppp (with
protocol lcp, ip, ipx), or slip, or arap or a specific command, the
daemon looks for a matching declarations for the user (or groups the
user is a member of).
For exec startup, it looks for a "service=exec" OR any command
configured.
For ppp, it looks for a "service=ppp" and "protocol=(one of lcp, ip,
ipx)".
For slip there must be a "service=slip" and for arap a "service=arap"
clause.
For specific commands, there must be a matching cmd=<cmdname>.
If these aren't found, authorization will fail, *unless* you say
"default service = permit".
Q). How do I make PAP work?
A). Avoid using PAP if possible since it's not very secure. If you
*must* use it, PAP passwords may be specified along with arap and chap
passwords for each user. Note that the details of this changed in
version 3.0 and onwards.
For outbound PAP, where you are forced to send a password to the
remote host to identify yourself, there is now a separate "opap"
directive e.g.
opap = cleartext OOOO
You use this to set the outbound PAP password. It must be a cleartext
password.
NOTE: It is very bad practice to use an outbound PAP password that is
the same as any of your inbound passwords. For this reason, a "global"
password does not apply to outbound PAP, only to inbound PAP,
bidirectional CHAP and ARAP.
Before 3.0, PAP logins were treated like ordinary user logins, so you
needed to declare a user in the Daemon configuration file whose name
was typically the remote hostname (or user), with a login password, in
order to process the PAP request.
Q). How can I deny some one from telneting from a commserver by ip
address only. i.e. when command is 10.0.1.6 rather than telnet
10.0.1.6.
A). The best way to restrict telnet access is by applying an outbound
access list via the access class command (or equivalently, via the
"acl" avpair). The NAS configuration command "access-class <n> out"
for example applies a pre-defined standard IP access list (where n is
a number from 1 through 99) that governs telnet access from a NAS.
E.g. the following configuration commands permit outgoing Telnet
access from line 1 on the NAS *only* to hosts on network 192.85.55.0:
access-list 12 permit 192.85.55.0 0.0.0.255
line 1
access-class 12 out
Note: you must define "access-list 12 permit 192.85.55.0 0.0.0.255" on
the NAS. Only then can you use the acl avpair to apply it to a line
that a user dials in on.
Alternatively, you can try configuring "transport preferred none" on
the lines in question. This will force a user to always type "telnet
10.0.1.6" in order to telnet out from the NAS. Then you can apply
command authorization to this command to restrict it.
Q). I have an autocommand configured in the NAS-local database and I'm
using "aaa authentication local-override". The autocommand doesn't
work, but the username/password does. Why?
A). The "local-override" only applies to the authentication portion of
the local database, so if you want an autocommand for this user, you
need to also do:
aaa authorization exec local if-authenticated
This will use the local DB entry if one exists, allow authenticated
users otherwise, or fail.
We don't have a "aaa authorization local-override" like we do for
authentication. Unlike authentication, the local method for
authorization is sort of equivalent to a local-override.
Q). Can tacacs+ only be enabled on a global basis? I want to
selectively turn it on for, e.g. only modem-connected lines. How do I
do this?
A). You turn tacacs+ ON on a global basis, but you can then change the
behavior of individual lines to whatever you want, e.g.
aaa authentication login default tacacs+ none
aaa authentication login oldstyle line
aaa authentication login none none
line 1 16
login authentication default
line vty 0 4
login authentication oldstyle
line 0
login authentication none
Note that unfortunately, you can't (yet) apply authorization
differently to selected lines and interfaces.
Q). I have leased lines running PPP, and AAA authorization is also
configured, so the authorization on the leased lines fails. What should
I do?
A). Since you can't (yet) configure authorization on a per-line basis,
you have to turn on authentication on the leased lines running PPP and
configure your T+ server so that it will authorize these lines
correctly.
A more demanding alternative is to modify the TACACS+ server source code
to allow any authorizations coming in from the port "SerialXXX" to
succeed.
A third possibility is to not use PPP on those lines, e.g. use HDLC
instead. HDLC doesn't require authentication or authorization.
Q). What are the memory recommendations for TACACS+?
A). Unless you're using passwd style files, TACACS+ holds entries in
hash tables in memory. The overhead is modest e.g. each user entry
occupies 72 bytes, plus space for strings like username and password
etc. Access time should thus be pretty constant regardless of number
of users. On a sparc 2, a config file containing 2000 users requires
about 0.5M of swap.
Q). How many users will a TACACS+ server support? What happens when
the maximum is exceeded?
There are 2 issues. The first is that each entry in the config file
occupies memory (swap space) so you could run out of swap space either
starting up the daemon or when it forks to answer incoming requests
(see above). If this happens, the daemon will drop the connection
which should appear as an error to the NAS) and the logfile will
contain appropriate error messages. The solution is usually to add
more disk space for swapping.
The second issue is speed: Using config files containing 75,000 user
entries, I'm seeing about 3 authentications per second on a sparc 2
without noticeable performance impact, though I haven't benchmarked
this formally.
So more than about 3 authentications per second on this platform will
result in users seeing delays and having to wait for prompts. The
usual solution to this is to add more daemons to spread the load out.
Q). How many characters may a TACACS+ Username and Password contain?
A). The short answer is 31 bytes of username, with up to 254 bytes of
password if they are cleartext (8 bytes if passwords are des
encrypted).
The long answer is that the Cisco NAS allocates a buffer of 1024
bytes, so this is the maximum you can type in, in response to a NAS
prompt.
But the protocol spec allows a username or password length field of
just one byte in an authentication packet, so only the first 255 of
these characters can be sent to the daemon.
Then, the API spec states that the username in the identity structure
on the daemon is 32 bytes long, so only the first 31 bytes of username
will be copied from the authentication packet into this structure,
which is then null-terminated.
The password, on the other hand, is copied into malloc'ed memory, so
it can still be up to 255 characters long.
Now if it's a des encrypted password, then only the first 8 bytes are
significant, per the common unix implementations of crypt.
Lastly, there is also the question of how long a username/password can
be configured in the daemon configuration file. The answer is given by
the value of MAX_INPUT_LINE_LEN, currently set to 255, which
determines the length of the longest string you can enter in the
configuration file.
Q). What is the format of accounting records?
Accounting records are text lines containing tab-separated fields. The
first 6 fields are always the same. These are:
timestamp, NAS name, username, port, address, record type.
Following these, a variable number of fields are written, depending on
the accounting record type. All are of the form attribute=value. There
will always be a task_id field.
Current attributes are:
"unknown"
"service"
"start_time"
"port"
"elapsed_time"
"status"
"priv_level"
"cmd"
"protocol"
"cmd-arg"
"bytes_in"
"bytes_out"
"paks_in"
"paks_out"
"address"
"task_id"
"callback-dialstring"
"nocallback-verify"
"callback-line"
"callback-rotary"
I expect more will be added over time.
Example records are thus:
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
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
Thu Jul 13 14:09:02 1995 cherub.cisco.com billw tty18 171.69.1.152 start task_id=17150 service=exec port=18
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
Elapsed time is in seconds, and is the field most people are usually
interested in.
Q). How do I limit the number of sessions a user can have?
A). The TACACS+ daemon can enforce how many simultaneous sessions a
given user is allowed to have. You must compile the daemon with the
MAXSESS symbol defined (see the Makefile).
Maximum sessions are configured on the daemon for a user as follows:
user = joeslip {
login = cleartext XXX
# only allow two sessions max for joeslip
maxsess = 2
name = "Joe SLIP User"
...
}
It can also be configured under a group:
group = slip_users {
maxsess = 2
...
}
...
user = fred {
...
member = slip_users
...
}
The daemon keeps a count of how many sessions a given user owns by
monitoring START and STOP accounting records. Thus, exec and network
accounting must be configured for this feature to operate for exec and
ppp users.
As the restriction is enforced during the authorization phase of
login, exec and network authorization must be configured as well, viz:
aaa authentication login default tacacs+
aaa authentication ppp default tacacs+
aaa authorization exec tacacs+
aaa authorization network tacacs+
aaa accounting exec start-stop tacacs+
aaa accounting network start-stop tacacs+
Due to network outages (or other disruptions), it is possible for the
TACACS+ daemon's record of usage to become out of sync with reality,
so before denying access because it thinks a user is running too many
sessions, the TACACS+ daemon will use the finger service on the NAS to
verify how many sessions a user is running there.
If the result of finger indicates that the daemon should permit
access, access will be granted. Note that for this check to work via
finger, "service finger" must also be configured on the NAS.
Lastly, note that because finger output truncates usernames at 10
characters, you may encounter trouble if you have users whose names
are not unique within those first 10 characters.
v
Also recall that authorization works differently on the console. So
many people locked themselves out of their boxes after configuring
authorization, that we stopped requiring authorization on the console
for authenticated users. Since there's no authorization on the
console, MAXSESS is not enforced there.
Q). How can I configure time-outs on an interface via Tacacs+?
A). Certain per-user/per-interface timeouts may be set by Tacacs+
during authorization. As of 11.0, you can set an arap session timeout,
and an exec timeout. As of 11.1 you can also set an exec idle timeout.
There are currently no settable timeouts for PPP or SLIP sessions, but
there is a workaround which applies to ASYNC PPP/SLIP idle timeouts
started via exec sessions only: This workaround is to set an EXEC
(idletime) timeout on an exec session which is later used to start up
PPP or SLIP (either via a T+ autocommand or via the user explicitly
invoking PPP or SLIP). In this case, the exec idle timeout will
correctly terminate an idle PPP or SLIP session. Note that this
workaround cannot be used for sessions which autoselect PPP or SLIP.
An idle timeout terminates a connection when the interface is idle for
a given period of time (this is equivalent to the "session-timeout"
Cisco IOS configuration directive). The other timeouts are
absolute. Of course, any timeouts set by Tacacs+ apply only to the
current connection.
user = lol {
login = cleartext foobar
service = exec {
# disconnect lol if there is no traffic for 5 minutes
idletime = 5
# disconnect lol unconditionally after one hour
timeout = 60
}
You also need to configure exec authorization on the NAS for the above
timeouts, e.g.
aaa authorization exec tacacs+
Note that these timeouts only work for async lines, not for ISDN
currently.
Note also that you cannot use the authorization "if-authenticated"
option with these parameters, since that skips authorization if the
user has successfully authenticated.
Q). How do I send VPDN forwarding decisions to an authorization
server?
A). In 11.2 onwards, VPDN NASs can use T+ to allow an authorization
server to make the decision to forward users.
If VPDN forwarding is turned on, and the username is of the form
user@domain, and "domain" matches a vpdn outgoing configured domain,
then an authorization attempt is made for "domain" (see below).
When making an authorization call for VPDN, a service type of "ppp"
with a protocol type of "vpdn", with a username of "domain" will be
made e.g. when a PPP user comes up on a line with the username
foo@bar.com, if "vpdn enable" and "aaa authorization ...." is enabled
on the box, then a one-time authorization of the name "bar.com" is
attempted.
If this authorization is successful, no local authentication is
attempted on the NAS, and the connection is forwarded via VPDN
instead.
If no VPDN-specific information comes back from this authorization
call, the login proceeds as follows:
If tacacs-server directed-requests are configured (note: this is true
by default), then IOS will strip off the domain part of a name of the
form user@domain and use "domain" to try and select a T+ server. If
successful, the username portion "user", without the domain, will be
used for all subsequent authentication, authorization and accounting.
If directed requests are turned off, then the entire username
user@domain is treated as a username.
vpdn specific information includes the attributes "tunnel-id",
"source-ip" (deprecated) and "ip-addresses":
tunnel-id:
This AV pair specifies the username that will be used to
authenticate the tunnel over which the individual user MID
will be projected. This is analogous to the "NAS name" in the
"vpdn outgoing" command.
ip-addresses:
This is a list of possible IP addresses that can be used for
the end-point of the tunnel. Consult the text at the end of
this document for more details on how to configure this
attribute.
source-ip: (This is now deprecated. It began in release 11.2(1.4),
and was removed in 11.2(4.0.2)).
This ip address will be used as the source of all VPDN packets
generated as part of the VPDN tunnel (see the source-ip
keyword in the vpdn outgoing command).
Tacacs+ syntax
--------------
The following syntax is used on the public domain Tacacs+ server.
username = domain {
service = ppp protocol = vpdn {
tunnel-id = <name for tunnel authentication>
ip-addresses = <addr> [<addr> ...]
source-ip = <ip-address>
}
}
In addition the T+ server can be used to store the usernames for both
the NAS (the username specified by "tunnel-id" above) and the Home
Gateway. These will be used to authenticate the tunnel.
Example:
user = foobar.cisco.com {
service = ppp protocol = vpdn {
tunnel-id = my_nas
ip-addresses = "173.20.12.19 173.20.12.20"
source-ip = 173.5.10.1
}
}
user = my_nas {
global = cleartext egad
}
user = my_home_gateway {
global = cleartext wowser
}
IOS Configuration
-----------------
To enable AAA assisted VPDN forwarding on a NAS, the following minimum
configuration is required:
vpdn enable
aaa new-model
aaa authorization network tacacs+ ...
In addition, if the passwords for the home gateway and NAS are stored
on the T+ daemon, the command
aaa authentication login tacacs+ ....
should also be present.
Beginning with release 11.2(1.4), the additional configuration
vpdn outgoing cisco.com ip NAS [ source-ip X.X.X.X ]
can be used. This changes in 11.2(4.0.2) and becomes:
vpdn source-ip X.X.X.X
vpdn outgoing cisco.com ip NAS
Q). Can someone expand on the use of the "optional" keyword.
A). Most attributes are mandatory i.e. if the daemon sends them to the
NAS, the NAS must obey them or deny the authorization. This is the
default. It is possible to mark attributes as optional, in which case
a NAS which cannot support the attribute is free to simply ignore it
without causing the authorization to fail.
This was intended to be useful in cutover situations where you have
multiple NASes running different versions of IOS, some of which
support more attributes than others. If you make the new attributes
optional, older NASes could ignore the optional attributes while new
NASes could apply them. Note that this weakens your security a little,
since you are no longer guaranteed that attributes are always applied
on successful authorization, so it should be used judiciously.
Q). Can I do do address pooling on the T+ daemon?
A). Not really since nothing on the daemon tracks whether an address
is already in use. The best way to do manage address pools is to
define a non-overlapping pool of addresses on each NAS and return the
name of this pool during authorization whenever a user logs in e.g.
NAS:
ip local pool foo 1.0.0.1 1.0.0.10
Daemon:
user = lol {
service = ppp protocol = ip {
addr-pool = foo
}
}
Q). What about MSCHAP?
A). Version F4.X contains mschap support. Mschap is configured the
same way as chap, only using the "mschap" keyword in place of the
"chap" keyword.
Like ARAP, MSCHAP works best when you have a des library (see the note
at the beginning of this document), but this is optional, as the DES
calculation can be done by the NAS instead. It also optionally
requires a key from Microsoft which is not public domain, but this can
also be done on the NAS too, so you can live without it.
To compile the daemon with MSCHAP support, uncomment the MSCHAP line
in the Makefile. This will add the MSCHAP code to your daemon. You can
leave MSCHAP_DES undefined, in which case the MSCHAP DES calculation
will be done by NAS, and no special MSCHAP key will be required.
If you have a DES library and want to use it with MSCHAP (this is more
efficient for authentication), then you can also uncomment the
MSCHAP_DES and MSCHAP_MD4_SRC lines in the Makefile. This will ensure
that the DES calculation done in the daemon. A key will need to be
obtained from Microsoft and used to replace the definition of
MSCHAP_KEY in the file mschap.h. If you're thinking by now that this
is all too much trouble, I can't say I blame you....
Q). Can I do wtmp-style logging like xtacacd used to do?
A). Wtmp file logging is supported. The "-u <wtmpfilename>" command
line flag can be used to specify a filename which will be used for
logging wtmp style records instead of the regular T+ accounting
records.
wtmp records are generated into wtmpfilename. Since file locking is
also used when writing to wtmpfilename, the usual provisos regarding
NFS and locking (see accounting above) should be observed.
To generate correct wtmp log records, the NAS needs to be configured
as follows:
aaa accounting exec stop-only tacacs+
aaa accounting network stop-only tacacs+
aaa accounting system start-stop tacacs+
CANNED CONFIGURATIONS
---------------------
Here are some canned configurations for getting demos started:
1). A canned configuration for login authentication only. This allows
user fred to login with password "abcdef". If the tacacs+ server dies,
the enable secret will be accepted as a login password instead.
DAEMON:
key = <some key>
# repeat as necessary for each user
user = fred {
login = cleartext abcdef
}
NAS:
aaa new-model
enable secret foobar
! use tacacs+. If server dies, use the enable secret password
aaa authentication login default tacacs+ enable
tacacs-server host <some host ip address>
tacacs-server key <some key>
2). A canned configuration for command authorization. This will allow
user fred to login with password abcdef and to run the privileged
(level 15) commands 'write terminal' and 'configure'. All other
privileged commands will be denied.
The "none" keyword in the NAS configuration line means that if the
tacacs+ server dies, any command will be allowed.
DAEMON:
key = <some key>
# repeat as necessary for each user
user = fred {
login = cleartext abcdef
cmd = write {
permit terminal
}
cmd = configure {
permit .*
}
}
NAS:
aaa new-model
! all level 15 (privileged commands). If server dies, allow everything
aaa authorization commands 15 tacacs+ none
tacacs-server host <some host ip address>
tacacs-server key <some key>
3). Canned configuration for network access authorization. This config
allows "fred" to login to line 1 with password abcdef (or to and to
run ppp using chap authentication. The chap password is "lab".
DAEMON:
key = <some key>
# repeat as necessary for each user
user = fred {
login = cleartext abcdef
chap = cleartext lab
service = ppp protocol = ip {
addr=1.0.0.2
}
}
NAS:
aaa new-model
! authenticate exec logins (if not autoselecting)
aaa authentication login default tacacs+
! authorize network services via tacacs+
aaa authorization network tacacs+
! use tacacs+ for authenticating ppp users
aaa authentication ppp default tacacs+
tacacs-server host <some host ip address>
tacacs-server key <some key>
interface Async1
ip address 1.0.0.1 255.0.0.0
async default ip address 172.21.14.55
encapsulation ppp
async dynamic address
async mode interactive
! use chap to authenticate ppp users
ppp authentication chap
line 1
! need "modem inout" here and flow control if using a modem
4). Canned configuration for ARAP.
NAS:
aaa new-model
aaa authentication arap default guest tacacs+
aaa authorization network tacacs+
aaa accounting network start-stop tacacs+
!
appletalk routing
arap network <number> <name>
!
interface Ethernet0
appletalk cable-range <range>
appletalk zone <zonename>
!
tacacs-server host <host>
tacacs-server key <key>
!
line 1
location a modem
modem answer-timeout 0
modem InOut
autoselect arap
autoselect during-login
arap enable
speed <speed>
flowcontrol hardware
Daemon:
key = "some key"
user = lol {
arap = cleartext <arap secret>
service = arap { }
}
Authorization AV pairs
----------------------
The following authorization AV pairs are supported by 10.3(3) onwards
except where specifically noted.
The following AV pairs specify which service is being authorized. They
are typically accompanied by protocol AV pairs and other, additional
pairs from the lists below.
service=arap
service=shell (for exec startup, and also for command authorizations)
service=ppp
service=slip
service=system (not used).
service=raccess
Used for managing reverse telnet connections e.g.
user = jim {
login = cleartext lab
service = raccess {
port#1 = nasname1/tty2
port#2 = nasname2/tty5
}
}
Requires IOS configuration
aaa authorization reverse-access tacacs+
See the IOS docs for more details.
protocol=lcp
The lower layer of PPP, always brought up before IP, IPX, etc.
is brought up.
protocol=ip
Used with service=ppp and service=slip to indicate which
protocol layer is being authorized.
protocol=ipx
Used with service=ppp to indicate which protocol layer
is being authorized.
protocol=atalk
with service=ppp or service=arap
protocol=vines
For vines over ppp.
protocol=ccp
Authorization of CCP. Compression Control Protocol). No other
av-pairs associated with this.
protocol=cdp
Authorization of CDP (Cisco Discovery Protocol). No other
av-pairs associated with this.
protocol=multilink
Authorization of multilink PPP. See 'max-links' and 'load-threshold'.
protocol=unknown
For undefined/unsupported conditions. Should not occur under
normal circumstances.
cmd (EXEC)
If the value of cmd is NULL e.g. the AV pair is cmd=, then
this is an authorization request for starting an exec.
If cmd is non-null, this is a command authorization request,
It contains the name of the command being authorized
e.g. cmd=telnet
cmd-arg (EXEC)
During command authorization, the name of the command is given
by an accompanying "cmd=" AV pair, and each command argument
is represented by a cmd-arg AV pair e.g. cmd-arg=archie.sura.net
NOTE: 'cmd-arg' should never appear in a configuration file.
It is used internally by the daemon to construct a string
which is then matched against the regular expressions which appear
in a cmd clause in the configuration file.
acl (ARAP, EXEC)
For ARAP this contains an access-list number. For EXEC
authorization it contains an access-class number, e.g. acl=2.
which is applied to the line as the output access class equivalent
to the configuration command
line <n>
access-class 2 out
An outbound access-class is the best way to restrict outgoing telnet
connections. Note that a suitable access list (in this case,
numbered 2) must be predefined on the NAS.
inacl (PPP/IP/IPX)
This AV pair contains an IP or IPX input access list number
for slip or PPP e.g. inacl=2. The access list itself must be
pre-configured on the Cisco box. Per-user access lists do not
work with ISDN interfaces unless you also configure a virtual
interface. After 11.2(5.1)F, you can also use the name of a
predefined named access list, instead of a number, for the
value of this attribute.
Note: For IPX, inacl is only valid after 11.2(4)F.
inacl#<n> (PPP/IP, PPP/IPX, 11.2(4)F)
This AV pair contains the definition of an input access list
to be installed and applied to an interface for the duration
of the current connection, e.g.
inacl#1="permit ip any any precedence immediate"
inacl#2="deny igrp 0.0.1.2 255.255.0.0 any"
Attributes are sorted numerically before they are applied.
For IP, standard OR extended access list syntax may be used,
but it is an error to mix the two within a given access-list.
For IPX, only extended access list syntax may be used.
See also:
sho ip access-lists
sho ip interface
sho ipx access-lists
sho ipx interface
debug aaa author
debug aaa per-user
outacl (PPP/IP, PPP/IPX)
This AV pair contains an IP or IPX output access list number
for SLIP. PPP/IP or PPP/IPX connections e.g. outacl=4. The
access list itself must be pre-configured on the Cisco
box. Per-user access lists do not work with ISDN interfaces
unless you also configure a virtual interface. PPP/IPX is
supported in 11.1 onwards only. After 11.2(5.1)F, you can also
use the name of a predefined named access list, as well as a
number, for the value of this attribute.
outacl#<n> (PPP/IP, PPP/IPX, 11.2(4)F)
This AV pair contains an output access list definition to be
installed and applied to an interface for the duration of the
current connection, e.g.
outacl#1="permit ip any any precedence immediate"
outacl#2="deny igrp 0.0.9.10 255.255.0.0 any"
Attributes are sorted numerically before they are applied.
For IP, standard OR extended access list syntax may be used,
but it is an error to mix the two within a given access-list.
For IPX, only extended access list syntax may be used.
See also:
sho ip access-lists
sho ip interface
sho ipx access-lists
sho ipx interface
debug aaa author
debug aaa per-user
addr (SLIP, PPP/IP)
The IP address the remote host should be assigned when a slip
or PPP/IP connection is made e.g. addr=1.2.3.4
routing (SLIP, PPP/IP)
Equivalent to the /routing flag in slip and ppp commands. Can
have as its value the string "true" or "false".
timeout (11.0 onwards, ARAP, EXEC)
Sets the time until an arap or exec session disconnects
unconditionally (in minutes), e.g. timeout=60
autocmd (EXEC)
During exec startup, this specifies an autocommand, like the
autocommand option to the username configuration command,
e.g. autocmd="telnet foo.com"
noescape (EXEC)
During exec startup, this specifies "noescape", like the
noescape option to the username configuration command. Can
have as its value the string "true" or "false",
e.g. noescape=true
nohangup (EXEC)
During exec startup, this specifies "nohangup", like the
nohangup option to the username configuration command. Can
have as its value the string "true" or "false",
e.g. nohangup=true
priv-lvl (EXEC)
Specifies the current privilege level for command
authorizations, a number from zero to 15 e.g. priv_lvl=5.
Note: in 10.3 this attribute was priv_lvl i.e.
it contained an underscore instead of a hyphen.
zonelist (ARAP)
An Appletalk zonelist for arap equivalent to the line
configuration command "arap zonelist" e.g. zonelist=5
addr-pool (11.0 onwards, PPP/IP, SLIP)
This AV pair specifies the name of a local pool from which to
get the IP address of the remote host.
Note: addr-pool works in conjunction with local pooling. It
specifies the name of a local pool (which needs to be
pre-configured on the NAS). Use the ip-local pool command to
declare local pools, e.g on the NAS:
ip address-pool local
ip local pool foo 1.0.0.1 1.0.0.10
ip local pool baz 2.0.0.1 2.0.0.20
then you can use Tacacs+ to return addr-pool=foo or
addr-pool=baz to indicate which address pool you want to get
this remote node's address from, e.g. on the daemon:
user = lol {
service = ppp protocol = ip {
addr-pool=foo
}
}
route (11.1 onwards, PPP/IP, SLIP).
This AV pair specifies a route to be applied to an interface.
During network authorization, the "route" attribute may be
used to specify a per-user static route, to be installed via
Tacacs+.
The daemon side declaration is:
service=ppp protocol=ip {
route="<dst_addr> <mask> [ <gateway> ]"
}
This indicates a temporary static route that is to be
applied. "<dst_address>, <mask> and [<gateway>]" are expected
to be in the usual dotted-decimal notation, with meanings the
same as for the familiar "ip route" configuration command on a
NAS.
If gateway is omitted, the peer's address is taken to be the gateway.
The route is expunged once the connection terminates.
route#<n> (PPP/IP/IPX, 11.2(4)F)
Same as the "route" attribute, except that these are valid for
IPX as well as IP, and they are numbered, allowing multiple
routes to be applied e.g.
route#1="3.0.0.0 255.0.0.0 1.2.3.4"
route#2="4.0.0.0 255.0.0.0"
or, for IPX,
route#1="4C000000 ff000000 30.12.3.4"
route#2="5C000000 ff000000 30.12.3.5"
See also:
sho ip route
sho ipx route
debug aaa author
debug aaa per-user
callback-rotary (11.1 onwards, valid for ARAP, EXEC, SLIP or PPP)
The number of a rotary group (between 0 and 100 inclusive)
to use for callback e.g. callback-rotary=34. Not valid for ISDN.
callback-dialstring (11.1 onwards, valid for ARAP, EXEC, SLIP or PPP)
sets the telephone number for a callback e.g.
callback-dialstring=408-555-1212. Not valid for ISDN.
callback-line (11.1 onwards, valid for ARAP, EXEC, SLIP or PPP)
The number of a tty line to use for callback e.g.
callback-line=4. Not valid for ISDN.
nocallback-verify (11.1 onwards, valid for ARAP, EXEC)
Indicates that no callback verification is required. The only
valid value for this parameter is the digit one i.e.
nocallback-verify=1. Not valid for ISDN.
idletime (11.1 onwards, EXEC)
Sets a value, in minutes, after which an IDLE session will be
terminated. N.B. Does NOT work for PPP.
tunnel-id (11.2 onwards, PPP/VPDN)
This AV pair specifies the username that will be used to
authenticate the tunnel over which the individual user MID
will be projected. This is analogous to the "NAS name" in the
"vpdn outgoing" command.
ip-addresses (11.2 onwards, PPP/VPDN)
This is a space separated list of possible IP addresses that
can be used for the end-point of the tunnel.
In 11.2(5.4)F, this attribute was extended as follows:
1) comma (',') is also consider as a delimiter
For example the avpair can now be written as
ip-addresses = 172.21.9.26,172.21.9.15,172.21.9.4
2) '/' is considered a priority delimiter. When you have a
number of Home Gateway routers, it is desirable to consider some
as the primary routers and some as backup routers.
The '/' allow you to config the routers into priority groups,
so that the NAS will try to forward the users to the high
priority routers, before forwarding to the low priority one.
For example in the following avpair:
ip-addresses = "172.21.9.26 / 172.21.9.15 / 172.21.9.4"
172.21.9.26 is considered to be priority 1
172.21.9.15 is considered to be priority 2
172.21.9.4 is considered to be priority 3
The NAS will try to forward the users to 172.21.9.26, before
trying 172.21.9.15. If the NAS can't forward users to
172.21.9.26, it will try 172.21.9.15 next. If it fails with
172.21.9.15, it will then try forwarding to 172.21.9.4.
source-ip (PPP/VPDN, now deprecated, only existed in releases 11.2(1.4)
thru 11.2(4.0.2)). This specifies a single ip address will be
used as the source of all VPDN packets generated as part of
the VPDN tunnel (see the equivalent source-ip keyword in the
IOS vpdn outgoing command).
nas-password (PPP/VPDN, 11.2(3.4)F, 11.2(4.0.2)F)
During L2F tunnel authentication, nas-password specifies the password
for the NAS.
gw-password (PPP/VPDN, 11.2(3.4)F, 11.2(4.0.2)F)
During L2F tunnel authentication, gw-password specifies the password
for the home gateway.
rte-ftr-in#<n> (PPP -- IP/IPX, 11.2(4)F)
This AV pair specifies an input access list definition to be
installed and applied to routing updates on the current
interface, for the duration of the current connection.
For IP, both standard and extended Cisco access list syntax is
recognised, but it is an error to mix the two within a given
access-list.
For IPX, only Cisco extended access list syntax is legal.
Attributes are sorted numerically before being applied. For
IP, the first attribute must contain the name of a routing
process and its identifier (except for rip, where no
identifier is needed), e.g.
rte-fltr-in#0="router igrp 60"
rte-fltr-in#1="permit 0.0.3.4 255.255.0.0"
rte-fltr-in#2="deny any"
For IPX, no routing process is needed, e.g.
rte-fltr-in#1="deny 3C01.0000.0000.0001"
rte-fltr-in#2="deny 4C01.0000.0000.0002"
See also:
show ip access-lists
show ip protocols
sho ipx access-lists
sho ipx interface
debug aaa author
debug aaa per-user
Related IOS commands:
IP:
router <routing process identifier>
[no] distribute-list <list-name> in <interface>
IPX:
ipx input-network-filter <access-list-number>
rte-ftr-out#<n> (PPP/IP, 11.2(4)F)
This AV pair specifies an input access list definition to be
installed and applied to routing updates on the current
interface, for the duration of the current connection.
For IP, both standard and extended Cisco access list syntax is
recognised, but it is an error to mix the two within a given
access-list.
Attributes are sorted numerically before being applied. The
first attribute must contain the name of a routing process and
its identifier (except for rip, where no identifier is
needed), e.g.
rte-fltr-out#0="router igrp 60"
rte-fltr-out#3="permit 0.0.5.6 255.255.0.0"
rte-fltr-out#4="permit any"
For IPX, no routing process is specified, e.g.
rte-fltr-out#1="deny 3C01.0000.0000.0001"
rte-fltr-out#2="deny 4C01.0000.0000.0002"
See also:
sho ipx access-lists
sho ipx interface
show ip access-lists
show ip protocols
debug aaa author
debug aaa per-user
Related IOS commands:
IP:
router <routing process identifier>
[no] distribute-list <list-name> in <interface>
IPX:
ipx output-network-filter <access-list-number>
sap#<n> (11.2(4)F PPP/IPX)
This AV pair specifies static saps to be installed for the duration
of a connection e.g.
sap#1="4 CE1-LAB 1234.0000.0000.0001 451 4"
sap#2="5 CE3-LAB 2345.0000.0000.0001 452 5"
The syntax of static saps is the same as that used by the IOS
"ipx sap" command.
See also:
sho ipx servers
debug aaa author
debug aaa per-user
Related IOS commands:
[no] ipx sap ....
route#<n> (PPP/IP/IPX, 11.2(4)F)
Same as the "route" attribute, except that these are valid for
IPX as well as IP, and they are numbered, allowing multiple
routes to be applied e.g.
route#1="3.0.0.0 255.0.0.0 1.2.3.4"
route#2="4.0.0.0 255.0.0.0"
or, for IPX,
route#1="4C000000 ff000000 30.12.3.4"
route#2="5C000000 ff000000 30.12.3.5"
See also:
sho ip route
sho ipx route
debug aaa author
debug aaa per-user
sap-fltr-in#<n> (PPP/IPX, 11.2(4)F)
This AV pair specifies an input sap filter access list
definition to be installed and applied on the current
interface, for the duration of the current connection.
Only Cisco extended access list syntax is legal, e.g
sap-fltr-in#1="deny 6C01.0000.0000.0001"
sap-fltr-in#2="permit -1"
Attributes are sorted numerically before being applied.
sho ipx access-lists
sho ipx interface
debug aaa author
debug aaa per-user
[no] ipx input-sap-filter <number>
sap-fltr-out#<n> (PPP/IPX 11.2(4)F)
This AV pair specifies an output sap filter access list
definition to be installed and applied on the current
interface, for the duration of the current connection.
Only Cisco extended access list syntax is legal, e.g
sap-fltr-out#1="deny 6C01.0000.0000.0001"
sap-fltr-out#2="permit -1"
Attributes are sorted numerically before being applied.
sho ipx access-lists
sho ipx interface
debug aaa author
debug aaa per-user
[no] ipx output-sap-filter <number>
pool-def#<n> (PPP/IP, 11.2(4)F)
This attribute is used to define ip address pools on the NAS.
During IPCP address negotiation, if an ip pool name is
specified for a user (see the addr-pool attribute), a check is
made to see if the named pool is defined on the NAS. If it is,
the pool is consulted for an ip address.
If the required pool is not present on the NAS (either in the
local config, or as a result of a previous download
operation), then an authorization call to obtain it is
attempted, using the special username:
<nas-name>-pools
where <nas-name> is the configured name of the NAS.
Note: This username can be changed using the IOS configuration
directive e.g.
aaa configuration config-name nas1-pools-definition.cisco.us
The pool-def attribute is used to define ip address pools for
the above authorization call e.g.
user = foo {
login = cleartext lab
service = ppp protocol = ip {
addr-pool=bbb
}
}
user = nas1-pools {
service = ppp protocol = ip {
pool-def#1 = "aaa 1.0.0.1 1.0.0.3"
pool-def#2 = "bbb 2.0.0.1 2.0.0.10"
pool-def#3 = "ccc 3.0.0.1 3.0.0.20"
pool-timeout=60
}
}
In the example above is a configuration file fragment for defining 3
pools named "aaa", "bbb" and "ccc" on the NAS named "nas1".
When the user "foo" refers to the pool named "bbb", if the
pool "bbb" isn't defined, the NAS will attempt to download the
definition contained in the "nas1-pools" entry.
The other pools will also be defined at the same time (or they
will be ignored if they are already defined).
Since this procedure is only activated when an undefined pool
is referenced, one way to redefine a pool once it has been
downloaded is to manually delete the definition e.g. by
logging into the NAS, enabling, and configuring:
config t
no ip local pool bbb
^Z
When a pool is deleted, there is no interruption in service
for any user who is currently using a pool address. If a pool
is deleted and then subsequently redefined to include a pool
address that was previously allocated, the new pool will pick
up the allocated address and track it as expected.
Since downloaded pools do not appear in the NAS configuration,
any downloaded pool definitions automatically disappear
whenever a NAS reboots. These pools are marked as "dynamic"
when they appear in the output of the "show ip local pools"
NAS command.
Since it is desirable not to have to manually delete pools to
redefine them, the AV pair pool-timeout=<n> can be used to
timeout any downloaded pool definitions. The timeout <n> is in
minutes.
The effect of the pool-timeout attribute is to start a timer
when the pool definitions are downloaded. When the timer
expires, the pools are deleted. The next reference to a
deleted pool via will cause a re-fetch of the pool
definitions. This allows pool changes to be made on the
daemon and propagated to the NAS in a timely manner.
See also:
sho ip local pool
sho ip local pool <pool-name>
IOS commands:
ip local pool <name> <start address> <end address>
old-prompts (PPP/SLIP)
This attribute is integrated into the following IOS images:
11.2(7.4)P 11.2(7.4) 11.1(13.1) 11.(16.2) 11.1(13.1)AA
11.1(13.1)CA 11.1(13.1)IA 11.2(8.0.1)F 11.0(16.2)BT)
This attribute allows providers to make the prompts in T+
appear identical to those of earlier systems (tacacs and
xtacacs). This will allow administrators to upgrade from
tacacs/xtacacs to T+ transparently to users.
The difference between the prompts is as follows:
In xtacacs, when the user types "slip" or "ppp" the system
prompts for an address followed by a password, whereas T+
prompts only for an address.
In xtacacs, if the user types "slip host" or "ppp host", the
system prompts for a password. In T+, there is no prompt.
Using this attribute, T+ can be made to mimic the prompting
behaviour of xtacacs, by configuring network authorization on
IOS, and using the "old-prompts=true" attribute value pair for
slip and ppp/ip, viz:
user = joe {
global = cleartext foo
service = exec {
}
service = slip {
default attribute = permit
old-prompts=true
}
service = ppp protocol = ip {
default attribute = permit
old-prompts=true
}
}
i.e. the prompts are controlled by the addition of the
"old-prompts=true" attribute.
max-links (PPP/multilink - Multilink parameter; 11.3)
This AV pair restricts the number of multilink bundle links
that a user can have.
The daemon side declaration is:
service=ppp protocol=multilink {
max-links=<n>
}
The range of <n> is [1-255].
Related NAS commands:
int <foo>
[no] ppp multilink
int virtual-template X
multilink max-links <n>
show ppp multilink
debug multilink
load-threshold (PPP/multilink - Multilink parameter; 11.3)
This AV pair sets the load threshold at which an additional
multilink link is added to the bundle (if load goes above) or
deleted (if load goes below).
The daemon side declaration is:
service=ppp protocol=multilink {
load-threshold=<n>
}
The range of <n> is [1-255].
Related NAS commands:
int <foo>
[no] ppp multilink
int virtual-template X
multilink load-threshold <n>
show ppp multilink
debug multilink
Reserved for future use:
ppp-vj-slot-compression
link-compression
asyncmap
x25-addresses (PPP/VPDN)
frame-relay (PPP/VPDN)
|