1USERS(5) FreeRADIUS user authorization file USERS(5)
2
6 users - user authorization file for the FreeRADIUS server
7
9 The users files reside in the files module configuration directory, by
10 default /etc/raddb/mods-config/files/. It contains a series of config‐
11 uration directives which are used by the files module to decide how to
12 authorize and authenticate each user request.
13 Every line starting with a hash sign ('#') is treated as comment and
15 ignored.
16 Each entry of the file begins with a username, followed by a (possibly
18 empty) list of check items, all on one line. The next line begins with
19 a tab, and a (possibly empty) list of reply items. Each item in the
20 check or reply item list is an attribute of the form name = value.
21 Multiple items may be placed on one line, in which case they must be
22 separated by commas. The reply items may be specified over multiple
23 lines, in which case each line must end with a comma, and the last line
24 of the reply items must not end with a comma.
25 The check items are a list of attributes used to match the incoming
27 request. If the username matches, AND all of the check items match the
28 incoming request, then the reply items are added to the list of
29 attributes which will be used in the reply to that request. This
30 process is repeated for all of the entries in the users file.
31 If the incoming request matches NO entry, then the request is rejected.
33
36 The special keyword DEFAULT matches any usernames.
37 The entries are processed in order, from the top of the users file, on
39 down. If an entry contains the special item Fall-Through = No as a
40 reply attribute, then the processing of the file stops, and no more
41 entries are matched. Any reply item list without any Fall-Through
42 attribute is treated as though it included a Fall-Through = No
43 attribute.
44 If an entry contains the special item Fall-Through = Yes as a reply
46 attribute, then the processing proceeds to the next entry in order.
47 Care should be taken when using Fall-Through. The server should be
49 tested in debugging mode with a number of test requests, in order to
50 verify that the configured entries behave as expected.
51 The special attribute Auth-Type is used to identify the authentication
53 type to be used for that user. See the dictionary file for a list of
54 permitted values for the Auth-Type attribute.
55 Once the users file has been processed, the request is authenticated,
57 using the method given by Auth-Type.
58
61 Additional operators other than = may be used for the attributes in
62 either the check item, or reply item list. The following is a list of
63 operators, and their meaning.
64 Attribute = Value
67 Not allowed as a check item for RADIUS protocol attributes. It is
68 allowed for server configuration attributes (Auth-Type, etc), and
69 sets the value of on attribute, only if there is no other item of
70 the same attribute.
71 As a reply item, it means "add the item to the reply list, but
72 only if there is no other item of the same attribute."
73 Attribute := Value
76 Always matches as a check item, and replaces in the configuration
77 items any attribute of the same name. If no attribute of that
78 name appears in the request, then this attribute is added.
79 As a reply item, it has an identical meaning, but for the reply
80 items, instead of the request items.
81 Attribute == Value
84 As a check item, it matches if the named attribute is present in
85 the request, AND has the given value.
86 Not allowed as a reply item.
87 Attribute += Value
90 Always matches as a check item, and adds the current attribute
91 with value to the list of configuration items.
92 As a reply item, it has an identical meaning, but the attribute is
93 added to the reply items.
94 Attribute != Value
97 As a check item, matches if the given attribute is in the request,
98 AND does not have the given value.
99 Not allowed as a reply item.
100 Attribute > Value
103 As a check item, it matches if the request contains an attribute
104 with a value greater than the one given.
105 Not allowed as a reply item.
106 Attribute >= Value
109 As a check item, it matches if the request contains an attribute
110 with a value greater than, or equal to the one given.
111 Not allowed as a reply item.
112 Attribute < Value
115 As a check item, it matches if the request contains an attribute
116 with a value less than the one given.
117 Not allowed as a reply item.
118 Attribute <= Value
121 As a check item, it matches if the request contains an attribute
122 with a value less than, or equal to the one given.
123 Not allowed as a reply item.
124 Attribute =* Value
127 As a check item, it matches if the request contains the named
128 attribute, no matter what the value is.
129 Not allowed as a reply item.
130 Attribute !* Value
133 As a check item, it matches if the request does not contain the
134 named attribute, no matter what the value is.
135 Not allowed as a reply item.
136
139 bob Cleartext-Password := "hello"
140 Requests containing the User-Name attribute, with value "bob",
142 will be authenticated using the "known good" password "hello".
143 There are no reply items, so the reply will be empty.
144 DEFAULT Service-Type == Framed-User, Framed-Protocol == PPP
146 Service-Type = Framed-User,
147 Framed-Protocol = PPP,
148 Fall-Through = Yes
149 If the request packet contains the attributes Service-Type and
151 Framed-Protocol, with the given values, then include those
152 attributes in the reply.
153 That is, give the user what they ask for. This entry also shows
155 how to specify multiple reply items.
156 See the users file supplied with the server for more examples and com‐
158 ments.
159
162 Run the server in debugging mode (-X), and use the radclient program to
163 send it test packets which you think will match specific entries. The
164 server will print out which entries were matched for that request, so
165 you can verify your expectations. This should be the FIRST thing you
166 do if you suspect problems with the file.
167 Care should be taken when writing entries for the users file. It is
169 easy to misconfigure the server so that requests are accepted when you
170 wish to reject them. The entries should be ordered, and the Fall-
171 Through item should be used ONLY where it is required.
172 Entries rejecting certain requests should go at the top of the file,
174 and should not have a Fall-Through item in their reply items. Entries
175 for specific users, who do not have a Fall-Through item, should come
176 next. Any DEFAULT entries should usually come last, except as fall-
177 through entries that set reply attributes.
178
181 /etc/raddb/mods-config/files/
182
184 radclient(1), radiusd(8), dictionary(5),
185
188 The FreeRADIUS team.
189 04 Jan 2004 USERS(5)