-
Notifications
You must be signed in to change notification settings - Fork 0
/
users_guide.in
2222 lines (1647 loc) · 70.7 KB
/
users_guide.in
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
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-1998 by Cisco systems, Inc.
Permission to use, copy, modify, and distribute this software for
any purpose and without fee is hereby granted, provided that this
copyright and permission notice appear on all copies of the
software and supporting documentation, the name of Cisco Systems,
Inc. not be used in advertising or publicity pertaining to
distribution of the program without specific prior permission, and
notice be given in supporting documentation that 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:
[email protected] (or more simply)
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:
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
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
[email protected]. 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)
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
---------------------------------
You link tac_plus with the supplied DES library for ARAP and MSCHAP with
configure's --enable-arapdes and --enable-mschapdes options. 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.
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
tac_convert.
CONVERTING EXISTING PASSWD(5) FILES
-----------------------------------
To convert an existing passwd(5) file e.g. one used with an older
version of tacacs, use the tac_convert perl script as follows:
tac_convert <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 4 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
}
4). Authentication using PAM (Pluggable Authentication Modules)
Assuming that your OS supports it, tac_plus can be configured to use PAM
for authentication, which may make it possible to use LDAP, SecureID, etc
if you have the appropriate PAM module. Use may require configuration of
the PAM libraries themselves; see their documentation.
user = fred {
login = PAM
}
Be aware that when the tac_plus daemon runs as a non-root user (as is the
default in FreeBSD /usr/ports), it will not be able to authenticate using
the pam_unix.so module. This is because the system function getpwnam()
called by pam_unix.so requires root privileges to retrieve the password to
validate from the /etc/master.passwd or /etc/shadow file. The symptom will
be that for each authentiction that is attempted, the password will appear
to be wrong whether it was typed correctly or not.
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 "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