1USERS(5) FreeRADIUS user authorization file USERS(5)
2
6 users - user authorization file for the FreeRADIUS server
7
9 The users file resides in the RADIUS database directory, by default
10 /etc/raddb. It contains a series of configuration directives which are
11 used by the files module to decide how to authorize and authenticate
12 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 seperated 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 username 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 =~ Expression
127 As a check item, it matches if the request contains an attribute
128 which matches the given regular expression. This operator may
129 only be applied to string attributes.
130 Not allowed as a reply item.
131 Attribute !~ Expression
134 As a check item, it matches if the request contains an attribute
135 which does not match the given regular expression. This operator
136 may only be applied to string attributes.
137 Not allowed as a reply item.
138 Attribute =* Value
141 As a check item, it matches if the request contains the named
142 attribute, no matter what the value is.
143 Not allowed as a reply item.
144 Attribute !* Value
147 As a check item, it matches if the request does not contain the
148 named attribute, no matter what the value is.
149 Not allowed as a reply item.
150
153 bob Cleartext-Password := "hello"
154 Requests containing the User-Name attribute, with value "bob",
156 will be authenticated using the "known good" password "hello".
157 There are no reply items, so the reply will be empty.
158 DEFAULT Auth-Type = System
160 Fall-Through = Yes
161 For all users reaching this entry, perform authentication
163 against the system, unless Auth-Type has already been set.
164 Also, process any following entries which may match.
165 DEFAULT Service-Type == Framed-User, Framed-Protocol == PPP
167 Service-Type = Framed-User,
168 Framed-Protocol = PPP,
169 Fall-Through = Yes
170 If the request packet contains the attributes Service-Type and
172 Framed-Protocol, with the given values, then include those
173 attributes in the reply.
174 That is, give the user what they ask for. This entry also shows
176 how to specify multiple reply items.
177 See the users file supplied with the server for more examples and com‐
179 ments.
180
183 Run the server in debugging mode (-X), and use the radclient program to
184 send it test packets which you think will match specific entries. The
185 server will print out which entries were matched for that request, so
186 you can verify your expectations. This should be the FIRST thing you
187 do if you suspect problems with the file.
188 Care should be taken when writing entries for the users file. It is
190 easy to misconfigure the server so that requests are accepted when you
191 wish to reject them. The entries should be ordered, and the Fall-
192 Through item should be used ONLY where it is required.
193 Entries rejecting certain requests should go at the top of the file,
195 and should not have a Fall-Through item in their reply items. Entries
196 for specific users, who do not have a Fall-Through item, should come
197 next. Any DEFAULT entries should usually come last, except as fall-
198 through entries that set reply attributes.
199
202 /etc/raddb/users
203
205 radclient(1), radiusd(8), dictionary(5), naslist(5)
206
209 The FreeRADIUS team.
210 04 Jan 2004 USERS(5)