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 re‐
27 quest. 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 at‐
29 tributes which will be used in the reply to that request. This process
30 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 re‐
40 ply attribute, then the processing of the file stops, and no more en‐
41 tries are matched. Any reply item list without any Fall-Through attri‐
42 bute is treated as though it included a Fall-Through = No attribute.
43 If an entry contains the special item Fall-Through = Yes as a reply at‐
45 tribute, then the processing proceeds to the next entry in order.
46 Care should be taken when using Fall-Through. The server should be
48 tested in debugging mode with a number of test requests, in order to
49 verify that the configured entries behave as expected.
50 The special attribute Auth-Type is used to identify the authentication
52 type to be used for that user. See the dictionary file for a list of
53 permitted values for the Auth-Type attribute.
54 Once the users file has been processed, the request is authenticated,
56 using the method given by Auth-Type.
57
60 Additional operators other than = may be used for the attributes in ei‐
61 ther the check item, or reply item list. The following is a list of
62 operators, and their meaning.
63 Attribute = Value
66 Not allowed as a check item for RADIUS protocol attributes. It is
67 allowed for server configuration attributes (Auth-Type, etc), and
68 sets the value of on attribute, only if there is no other item of
69 the same attribute.
70 As a reply item, it means "add the item to the reply list, but
71 only if there is no other item of the same attribute."
72 Attribute := Value
75 Always matches as a check item, and replaces in the configuration
76 items any attribute of the same name. If no attribute of that
77 name appears in the request, then this attribute is added.
78 As a reply item, it has an identical meaning, but for the reply
79 items, instead of the request items.
80 Attribute == Value
83 As a check item, it matches if the named attribute is present in
84 the request, AND has the given value.
85 Not allowed as a reply item.
86 Attribute += Value
89 Always matches as a check item, and adds the current attribute
90 with value to the tail of the list of configuration items.
91 As a reply item, it has an identical meaning, but the attribute is
92 added to the tail of the reply items list.
93 Attribute ^= Value
96 Always matches as a check item, and adds the current attribute
97 with value to the head of the list of configuration items.
98 As a reply item, it has an identical meaning, but the attribute is
99 added to the head of the reply items list.
100 Attribute != Value
103 As a check item, matches if the given attribute is in the request,
104 AND does not have the given value.
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 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 greater than, or equal to 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 the one given.
123 Not allowed as a reply item.
124 Attribute <= Value
127 As a check item, it matches if the request contains an attribute
128 with a value less than, or equal to the one given.
129 Not allowed as a reply item.
130 Attribute =* Value
133 As a check item, it matches if the request contains the named at‐
134 tribute, no matter what the value is.
135 Not allowed as a reply item.
136 Attribute !* Value
139 As a check item, it matches if the request does not contain the
140 named attribute, no matter what the value is.
141 Not allowed as a reply item.
142
145 bob Cleartext-Password := "hello"
146 Requests containing the User-Name attribute, with value "bob",
148 will be authenticated using the "known good" password "hello".
149 There are no reply items, so the reply will be empty.
150 DEFAULT Service-Type == Framed-User, Framed-Protocol == PPP
152 Service-Type = Framed-User,
153 Framed-Protocol = PPP,
154 Fall-Through = Yes
155 If the request packet contains the attributes Service-Type and
157 Framed-Protocol, with the given values, then include those at‐
158 tributes in the reply.
159 That is, give the user what they ask for. This entry also shows
161 how to specify multiple reply items.
162 See the users file supplied with the server for more examples and com‐
164 ments.
165
168 Run the server in debugging mode (-X), and use the radclient program to
169 send it test packets which you think will match specific entries. The
170 server will print out which entries were matched for that request, so
171 you can verify your expectations. This should be the FIRST thing you
172 do if you suspect problems with the file.
173 Care should be taken when writing entries for the users file. It is
175 easy to misconfigure the server so that requests are accepted when you
176 wish to reject them. The entries should be ordered, and the Fall-
177 Through item should be used ONLY where it is required.
178 Entries rejecting certain requests should go at the top of the file,
180 and should not have a Fall-Through item in their reply items. Entries
181 for specific users, who do not have a Fall-Through item, should come
182 next. Any DEFAULT entries should usually come last, except as fall-
183 through entries that set reply attributes.
184
187 /etc/raddb/mods-config/files/
188
190 radclient(1), radiusd(8), dictionary(5),
191
194 The FreeRADIUS team.
195 04 Jan 2004 USERS(5)